University of Southern California
Center for Systems and Software Engineering
ICSM Principle 2:
Incremental Commitment and Accountability
CS 510
Software Management and Economics
Fall 2015
Barry Boehm, USC
University of Southern California
Center for Systems and Software Engineering
Outline
• Nature of incremental commitment
• Failure story: Bank of America Master Net
• Success story: TRW Software Productivity System
• Alternative incremental commitment processes
8/26/2015
Copyright © USC-CSSE
2
University of Southern California
Center for Systems and Software Engineering
Nature of Incremental Commitment
• Successful system development projects
are built on a bedrock of trust
• Trust is built through effective
commitments
– Nature of commitments
• Premature commitments are risky
– The Cones of Uncertainty
– Best to commit incrementally
• The ICSM commitment stages
– Incremental definition and development
8/26/2015
Copyright © USC-CSSE
3
University of Southern California
Center for Systems and Software Engineering
Nature of Commitments
Watts Humphrey, 1989
• The person making the commitment does so willingly.
• The commitment is not made lightly; that is, the work
involved, the resources, and the schedule are carefully
considered.
• There is agreement between the parties as to what is to be
done, by whom, and when.
• The commitment is openly and publicly stated.
• The person responsible tries to meet the commitment, even if
help is needed.
• Prior to the committed date, if something changes that
impacts either party relative to the commitment, advance
notice is given and a new commitment is negotiated.
8/26/2015
Copyright © USC-CSSE
4
University of Southern California
Center for Systems and Software Engineering
The Cones of Uncertainty
– Need incremental definition and development
Uncertainties in competition,
technology, organizations,
mission priorities
8/26/2015
Copyright © USC-CSSE
5
University of Southern California
Center for Systems and Software Engineering
ICSM Stages and Phases
• Stage I: Incremental system definition
– Exploration Phase: Concurrently identifies and clarifies
system capability needs, constraints, and candidate solution
options
– Valuation Phase: Analyzes alternative solutions and
identifies preferred alternative
– Foundations Phase: Develops management and technical
foundations for the selected alternative
• Stage II: Incremental system development
– Development Phase: Procurement, iterative detailed design
and development, integration, and test of currentincrement components
– Production and Operations Phase: System “units”
produced, integrated, and put into operations
8/26/2015
Copyright © USC-CSSE
6
University of Southern California
Center for Systems and Software Engineering
The Incremental Commitment Spiral Process: Phased View
Anchor Point
Milestones
Synchronize, stabilize concurrency via FEDs
Risk patterns
determine life
cycle process
8/26/2015
Copyright © USC-CSSE
7
University of Southern California
Center for Systems and Software Engineering
Outline
• Nature of incremental commitment
• Failure story: Bank of America Master Net
• Success story: TRW Software Productivity System
• Alternative incremental commitment processes
8/26/2015
Copyright © USC-CSSE
8
University of Southern California
Center for Systems and Software Engineering
Failure Story: Bank of America Master Net
B of A Trust Management System (TMS)
• B of A an early leader in banking automation
– Electronic check processing, 1950s-1960s
• Lost automation leadership by late 1970s
– CEO agenda to “leapfrog into 1990s”
• Tried $6M in-house next-generation TMS development
– Extensive next-generation public relations push
– Results: missing capabilities; lack of scalability
– Embarrassing with respect to public relations push
• CEO appointed new TMS department head
– Modernize or discontinue TMS business
8/26/2015
Copyright © USC-CSSE
9
University of Southern California
Center for Systems and Software Engineering
B of A TMS Second Try: Master Net
• Develop full-capability requirements
– Union of customer wish lists: 3.5 million lines of code
– $22 million budget; 9 month full operational capability
• Look for best external TMS developer
– Premier Systems: several successful small-bank TMSs
– Lack of B of A system engineers to analyze proposals
• Contracted with Premier Systems March 1984
– $22 million; full commitment to deliver by December 1984
• December 1984: 100 programmers on-board
– Far from complete, even for demonstrations
– Many key stakeholder win condition conflicts
8/26/2015
Copyright © USC-CSSE
10
University of Southern California
Center for Systems and Software Engineering
ICSM Principles Counterexample:
Bank of America Master Net
11
8/26/2015
Copyright © USC-
University of Southern California
Center for Systems and Software Engineering
B of A/Premier TMS Development, 1985-88
• Serious corporate image problem if discontinued
– Added budget, developed 1985-86 schedule
• Organized major 1986 demonstration of working
capabilities
– Could not demonstrate performance scalability
– Still far from complete; many performance problems by end 1986
• 1987: Full-commitment TMS cutover to Master Net
– Serious performance, reliability problems, system crashes
– Premier Prime computer vs. BofA IBM interoperability problems
– Clients dropping off: 800->700 accounts; $38B->$34B assets
• May 1988: Transfer of TMS business to other banks
– Final 50-monthproject schedule, $80 million cost
8/26/2015
Copyright © USC-CSSE
12
University of Southern California
Center for Systems and Software Engineering
Principles Trump Diagrams: Master Net
1. Stakeholder value-based guidance
–
–
Overconcern with Voice of Customer: 3.5 MSLOC of rqts.
No concern with maintainers, interoperators: Prime vs. IBM
2. Incremental commitment and accountability
–
–
Total commitment to infeasible budget and schedule
No contract award fees or penalties for under/overruns
3. Concurrent multidiscipline engineering
–
–
No prioritization of features for incremental development
No prototyping of operational scenarios and usage
4. Evidence and risk-driven decisions
–
–
8/26/2015
No evaluation of Premier Systems scalability, performance
No evidence of ability to satisfy budgets and schedules
Copyright © USC-CSSE
13
University of Southern California
Center for Systems and Software Engineering
Outline
• Nature of incremental commitment
• Failure story: Bank of America Master Net
• Success story: TRW Software Productivity System
• Alternative incremental commitment processes
8/26/2015
Copyright © USC-CSSE
14
University of Southern California
Center for Systems and Software Engineering
Success story: TRW-SPS, 1980-82
Software Productivity System
• Major 1980 TRW corporate productivity initiative
– Need business case and plan
• COCOMO-based business case led to spiral plan
– Use of productivity opportunity tree
– Combination of technical, management, personnel initiatives
• First actual implementation of spiral model 1980-82
– Summaries of Exploration, Valuation, Foundations phases
• Results consistently improved productivity by factor of 2
– 1982 International Conference on Software Engineering Best Paper
8/26/2015
Copyright © USC-CSSE
15
University of Southern California
Center for Systems and Software Engineering
TRW - SPS, Exploration Phase
8/26/2015
Copyright © USC-CSSE
16
University of Southern California
Productivity Improvement Framework
Center for Systems and Software Engineering
Staffing, Incentivizing, Teambuilding
Facilities, Support Services
Kaizen (continuous improvement)
Get the Best from People
Tools and Automation
Work and Oversight Streamlining
Collaboration Technology
Make Tasks More Efficient
Productivity
Improvements
and Tradeoffs
Lean and Agile Methods
Eliminate Tasks
Task Automation
Model-Based Product Generation
Early Risk and Defect Elimination
Evidence-Based Decision Gates
Modularity Around Sources of Change
Incremental, Evolutionary Development
Value-Based, Agile Process Maturity
Eliminate Scrap, Rework
Risk-Based Prototyping
Simplify Products (KISS)
Value-Based Capability Prioritization
Satisficing vs. Optimizing Performance
Reuse Components
Domain Engineering and Architecture
Composable Components,Services, COTS
Legacy System Repurposing
Reduce Operations, Support Costs
Value- and Architecture-Based
Tradeoffs and Balancing
17
Copyright
© USC-CSSE
8/26/2015
Automate Operations Elements
Design for Maintainability, Evolvability
Streamline Supply Chain
Anticipate, Prepare for Change
University of Southern California
Center for Systems and Software Engineering
Costing Insights: COCOMO II Productivity Ranges
Scale Factor Ranges: 10, 100, 1000 KSLOC
Development Flexibility (FLEX)
Staffing
Team Cohesion (TEAM)
Develop for Reuse (RUSE)
Teambuilding
Precedentedness (PREC)
Architecture and Risk Resolution (RESL)
Continuous
Improvement
Platform Experience (PEXP)
Data Base Size (DATA)
Required Development Schedule (SCED)
Language and Tools Experience (LTEX)
Process Maturity (PMAT)
Storage Constraint (STOR)
Use of Software Tools (TOOL)
Platform Volatility (PVOL)
Applications Experience (AEXP)
Multi-Site Development (SITE)
Documentation Match to Life Cycle Needs (DOCU)
Required Software Reliability (RELY)
Personnel Continuity (PCON)
Time Constraint (TIME)
Programmer Capability (PCAP)
Analyst Capability (ACAP)
Product Complexity (CPLX)
1
1.2
1.4
1.6
1.8
2
2.2
2.4
Productivity Range
Copyright © USC-CSSE
18
8/26/2015
University of Southern California
Center for Systems and Software Engineering
TRW-SPS, Validation Phase
8/26/2015
Copyright © USC-CSSE
19
University of Southern California
Center for Systems and Software Engineering
TRW-SPS, Foundations Phase
8/26/2015
Copyright © USC-CSSE
20
University of Southern California
Center for Systems and Software Engineering
Outline
• Nature of incremental commitment
• Failure story: Bank of America Master Net
• Success story: TRW Software Productivity System
• Alternative incremental commitment processes
8/26/2015
Copyright © USC-CSSE
21
University of Southern California
Center for Systems and Software Engineering
Incremental and Evolutionary Acquisition Models
Type
Prespecified
Sequential
Evolutionary
Sequential
Evolutionary
Overlapped
(DoDI 5000.02)
Evolutionary
Concurrent
(ICSM)
Examples
Pros
Cons
Platform base plus
Pre-Planned Product
Improvements
Small: Agile
Larger: Rapid fielding
Prespecifiable fullcapability requirements,
scalability when stable
Adaptability to change,
need for usage feedback
Stable development;
Maturing technology
Mature technology
upgrades
Emergent requirements
or rapid change,
architecture breakers
Easiest-first; late, costly
fixes; SysE time gaps
Slow for large systems
Emergent requirements
or rapid change; SysE
time gaps
Rapid, emergent
development
Systems of systems
Emergent requirements
or rapid change, SysE
continuity
Overkill on small or
highly stable systems
Time phasing terms: Scoping; Architecting; Developing; Producing; Operating (SADPO)
Prespecified Sequential: SA; DPO1; DPO2; DPO3; …
Evolutionary Sequential: SADPO1; SADPO2; SADPO3; …
Evolutionary Overlapped: SADPO1;
SADPO2;
SADPO3; …
Evolutionary Concurrent: SA; D1 ; PO1…
SA2; D2 ; PO2…
SA3; D3; PO3 …
22
Copyright © USC-CSSE
8/26/2015
University of Southern California
Center for Systems and Software Engineering
Incremental Process Decision Table
Need to wait
for next increment
priorities?
Need to wait
for next increment
enablers*?
Stable, pre specifiable
requirements?
OK to wait for
full system to
be developed?
Pre-specified
Single -step
Yes
Yes
Pre-specified
Multi -step
Yes
No
Evolutionary
Sequential
No
No
Yes
Evolutionary
Opportunistic
No
No
No
Yes
Evolutionary
Concurrent
No
No
No
No
*Example enablers: Technology maturity; External-system capabilities; Needed
resources; New opportunities
8/26/2015
Copyright © USC-CSSE
23
University of Southern California
Center for Systems and Software Engineering
Risk-Driven Scalable Spiral Model: Increment View
For each level of systems-of-interest
Unforeseeable Change (Adapt)
Future Increment Baselines
Agile
Rebaselining for
Future Increments
Rapid
Change
Foreseeable
Change
(Plan)
Short
Development
Increments
Increment N Baseline
Stable Development
Increments
High
Assurance
Current V&V
Resources
Continuous V&V
8/26/2015
Deferrals
Short, Stabilized
Development
of Increment N
Artifacts
Operations and Maintenance
Concerns
Verification and
Validation (V&V)
of Increment N
Copyright © USC-CSSE
Increment N Transition/
Future V&V
Resources
24
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
8/26/2015
Recommend no action,
provide rationale
Change
Proposers
Prepare for rebaselined
future-increment
development
Copyright © USC-CSSE
25
University of Southern California
Center for Systems and Software Engineering
ICSM as Risk-Driven Process Generator
• Stage I of the ICSM has 3 decision nodes with 4
options/node
– Culminating with incremental development in Stage II
– Some options involve go-backs
– Results in many possible process paths
• Can use ICSM risk patterns to generate frequentlyused processes
– With confidence that they fit the situation
• Can generally determine this in the Exploration
phase
– Develop as proposed plan with risk-based evidence at VCR
milestone
– Adjustable in later phases
8/26/2015
Copyright © USC-CSSE
26
University of Southern California
Center for Systems and Software Engineering
Different Risk Patterns Yield Different Processes
8/26/2015
Copyright © USC-CSSE
27
27
University of Southern California
Center for Systems and Software Engineering
The ICSM Process Decision Table:
Key Decision Inputs
•
•
•
•
Product and project size and complexity
Requirements volatility
Mission criticality
Nature of Non-Developmental/COTS Item support
– Commercial, open-source, reused components
• Organizational and Personnel Capability
8/26/2015
Copyright © USC-CSSE
28
University of Southern California
Center for Systems and Software Engineering
The ICSM Process Decision Table:
Key Decision Outputs
• Key Stage I activities: incremental definition
• Key Stage II activities: incremental
development and operations
• Suggested calendar time per build, per
deliverable increment
8/26/2015
Copyright © USC-CSSE
29
University of Southern California
Center for Systems and Software Engineering
Common Risk-Driven Special Cases of the ICSM (Cases 1-4)
Case 1: Use NDI
Case 2: Agile
Example: Small accounting system
Size, Complexity: Size variable, complexity low
Typical Change Rate/Month: Negligible
Criticality: n/a
NDI Support: Complete
Organizational Personnel Capability: NDI-experienced (medium)
Key Stage I Activities (Incremental Definition): Acquire NDI
Key Stage II Activities (Incremental Development/Operations): Use
NDI
Time/Build: n/a
Time/Increment: Vendor-driven
Example: E-services
Size, Complexity: Low
Typical Change Rate/Month: 1-30%
Criticality: Low to medium
NDI Support: Good, in place
Organizational Personnel Capability: Agile-ready, medium-high
experience
Key Stage I Activities (Incremental Definition): Skip Valuation and
Architecting phases
Key Stage II Activities (Incremental Development/Operations): Scrum
plus agile methods of choice
Time/Build: <= 1 day
Time/Increment: 2-6 weeks
Case 3: Architected Agile
Case 4: Formal Methods
Example: Business data processing
Size, Complexity: Medium
Typical Change Rate/Month: 1-10 %
Criticality: Medium to high
NDI Support: Good, most in place
Organizational Personnel Capability: Agile-ready, medium to high
experience
Key Stage I Activities (Incremental Definition): Combine Valuation,
Architecting phases. Complete NDI preparation.
Key Stage II Activities (Incremental Development/Operations):
Architecture-based Scrum of Scrums
Time/Build: 2-4 weeks
Time/Increment: 2-6 months
8/26/2015
Example: Security kernel; Safety-critical LSI chip
Size, Complexity: Low
Typical Change Rate/Month: 0.3%
Criticality: Extra high
NDI Support: None
Organizational Personnel Capability: Strong formal methods experience
Key Stage I Activities (Incremental Definition): Precise formal
specification
Key Stage II Activities (Incremental Development/Operations):
Formally-based programming language; formal verification
Time/Build: 1-5 days
Time/Increment: 1-4 weeks
Copyright © USC-CSSE
30
University of Southern California
Center for Systems and Software Engineering
Common Risk-Driven Special Cases of the ICSM (Cases 5-8)
Case 5: Hardware with Embedded Software
Case 6: Indivisible IOC
Example: Multi-sensor control device
Size, Complexity: Medium
Typical Change Rate/Month: 0.3 - 1 %
Criticality: Medium to very high
NDI Support: Good, in place
Organizational Personnel Capability: Experienced, medium-high
Key Stage I Activities (Incremental Definition): Concurrent
hardware/software engineering. CDR-level ICSM DCR
Key Stage II Activities (Incremental Development/Operations): IOC
development, LRIP, FRP. Concurrent version N+1 engineering
Time/Build: Software 1-5 days
Time/Increment: Market-driven
Case 7: NDI-Intensive
Case 8: Hybrid Agile/Plan-Driven System
Example: Supply chain management
Size, Complexity: Medium to high
Typical Change Rate/Month: 0.3 – 3%
Criticality: Medium to very high
NDI Support: NDI-driven architecture
Organizational Personnel Capability: NDI-experienced, medium to
high
Key Stage I Activities (Incremental Definition): Thorough NDI-suite
life cycle cost-benefit analysis, selection, concurrent
requirements/architecture definition
Key Stage II Activities (Incremental Development/Operations): Proactive NDI evolution influencing, NDI upgrade synchronization
Time/Build: Software: 1-4 weeks
Time/Increment: Systems: 6-18 months
8/26/2015
Example: Complete vehicle platform
Size, Complexity: Medium to high
Typical Change Rate/Month: 0.3 – 1%
Criticality: High to very high
NDI Support: Some in place
Organizational Personnel Capability: Experienced, medium to high
Key Stage I Activities (Incremental Definition): Determine minimumIOC likely, conservative cost. Add deferrable software features as
risk reserve
Key Stage II Activities (Incremental Development/Operations): Drop
deferrable features to meet conservative cost. Strong award free for
features not dropped.
Time/Build: Software: 2-6 weeks
Time/Increment: Platform: 6-18 months
Example: C4ISR system
Size, Complexity: Medium to very high
Typical Change Rate/Month: Mixed parts; 1-10%
Criticality: Mixed parts; Medium to very high
NDI Support: Mixed parts
Organizational Personnel Capability: Mixed parts
Key Stage I Activities (Incremental Definition): Full ICSM,
encapsulated agile in high change, low-medium criticality parts
(Often HMI, external interfaces)
Key Stage II Activities (Incremental Development/Operations): Full
ICSM, three-team incremental development, concurrent V&V, nextincrement rebaselining
Time/Build: 1-2 months
Time/Increment: 9-18 months
Copyright © USC-CSSE
31
University of Southern California
Center for Systems and Software Engineering
Common Risk-Driven Special Cases of the ICSM (Cases 9-11)
Case 9: Multi-Owner System of Systems
Case 10: Family of Systems
Example: Net-centric military operations; Metro crisis management
Size, Complexity: Very high
Typical Change Rate/Month: Mixed parts; 1-10 %
Criticality: Very high
NDI Support: Many NDIs, some in place
Organizational Personnel Capability: Related experience, medium to
high
Key Stage I Activities (Incremental Definition): Full ICSM;
extensive multi-owner team building, negotiation
Key Stage II Activities (Incremental Development/Operations):
Full ICSM; large ongoing system/software engineering effort
Time/Build: 2-4 months
Time/Increment: 18-24 months
Example: Medical device product line
Size, Complexity: Medium to very high
Typical Change Rate/Month: 1-3%
Criticality: Medium to very high
NDI Support: Some in place
Organizational Personnel Capability: Related experience, medium to
high
Key Stage I Activities (Incremental Definition): Skip Valuation and
Architecting phases
Key Stage II Activities (Incremental Development/Operations):
Scrum plus agile methods of choice
Time/Build: 1-2 months
Time/Increment: 9-18 months
Case 11: Brownfield
Example: Incremental legacy phaseout
Size, Complexity: High to very high
Typical Change Rate/Month: 0.3-3%
Criticality: Medium-high
NDI Support: NDI as legacy replacement
Organizational Personnel Capability: Legacy re-engineering
Key Stage I Activities (Incremental Definition): Re-engineer/refactor legacy into services
Key Stage II Activities (Incremental Development/Operations): Incremental legacy phaseout
Time/Build: 2-6 weeks/refactor
Time/Increment: 2-6 months
8/26/2015
Copyright © USC-CSSE
32