1. A Winsor Brown CS 577b March 24, 2010
Incrementally Committed Acquisition (ICM nee Spiral) of Software-Intensive Systems of Systems
A Winsor Brown
CS 577b
March 24, 2010
9/22/2018
© USC-CSSE

2. Outline Definitions: Acquisition; SISOS
Trends in Software-Intensive Systems of Systems
Role of Incremental Commitment (nee Spiral) Development
Concurrent engineering of requirements and architecture; systems and software
Emphasis on risk management
Example system-of-systems top-10 risk list
Representative risks and mitigations
Incremental Commitment Alternative
Conclusions
9/22/2018
© USC-CSSE

3. Acquisition (DoD)
The acquisition process is structured by DoDI (DoD Instruction)
into discrete phases separated by major decision points (called milestones or decision reviews)
with a number of key activities to provide
the basis for comprehensive management and
informed decision making.
Details available at
Final back _singles.pdf
Final%20Ver%205%203%202%20Front%20draft%2011%20Dec% pdf
9/22/2018
© USC-CSSE

4. Acquisition (DoD) (cont.)
Life Cycle Management System Chart
a pictorial roadmap of key activities in the systems acquisition processes
illustrates the interaction of the three-key processes that must work in concert to deliver the capabilities required by the warfighters
the requirements process (Joint Capabilities Integration & Development System [JCIDS]);
the acquisition process (Defense Acquisition System); and
program and budget development (Planning, Programming, Budgeting, and Execution [PPBE] process).
9/22/2018
© USC-CSSE

5. Acquisition (DoD) (cont.)
9/22/2018
© USC-CSSE

6. SISOS System of Systems (SOS) Software Intensive (SI)
Planned/directed (relatively new)
Directed: not many
Acknowledged (lead by Sys of Sys Eng'g Group)
Federated (not single point of admin.)
Recognized
Ad hoc
Software Intensive (SI)
See “EC25b=SISoS--FCSexampleV0.doc”
9/22/2018
© USC-CSSE

7. Outline Definitions: Acquisition; SISOS
Trends in Software-Intensive Systems of Systems
Waterfall Legacies
Role of Spiral Development
Concurrent engineering of requirements and architecture; systems and software
Emphasis on risk management
Example system-of-systems top-10 risk list
Representative risks and mitigations
Incremental Commitment Alternative
Conclusions
9/22/2018
© USC-CSSE

8. Trends in Software-Intensive Systems
Transformational, network-centric systems
These are fundamentally software-intensive
Emphasis on joint, interoperable, capability-based systems
And increasingly, systems of systems
Increasing requirements emergence, COTS-dependence, environmental change
Traditional sequential acquisition practices increasingly inadequate
Fixed-requirements, -cost, -schedule contracting
Waterfall legacies: MIL-STD-1521B, parts of Software CMM
9/22/2018
© USC-CSSE

9. Waterfall Legacies: SW CMM v.1.1
Requirements Management, Ability 1:
“Analysis and allocation of the system requirements
is not the responsibility of the software engineering group
but is a prerequisite for their work.”
Concurrent engineering emphasized in CMMI, DoDD , DoDI
9/22/2018
© USC-CSSE

10. History and Trends The waterfall model and its problems
Spiral model resolution of problems
Problems with spiral model
Initial resolution: win-win, anchor points
Further problems
Resolution with Incremental Commitment Model
9/22/2018
© USC-CSSE

11. Waterfall Model Risk Profile
Requirements
analysis
The most critical risks are architectural:
Performance (size, time, accuracy)
Interface integrity
System qualities (adaptability,
portability, etc.)
Specifications &
models
Design R i s k
Specifications & models
Code and unit test
Tested code
Subsystem integration
Executable subsystem
System integration
Executable system
Time
9/22/2018
© USC-CSSE

12. Conventional Software Process
Problem: Late Tangible Design Assessment
Standard sequence of events:
Early and successful design review milestones
Late and severe integration trauma
Schedule slippage
Progress
(% coded) /
100 90
Integration begins 80 70 60
Late design
breakage
Conventional 50 40 30 20 10
Design
Reviews
Time (months)
9/22/2018
© USC-CSSE

13. Sequential Engineering Neglects Risk
$100M
Arch. A:
Custom
many cache processors
$50M
Arch. B:
Modified
Client-Server
Original Spec
After Prototyping 1 2 3 4 5
Response Time (sec)
9/22/2018
© USC-CSSE

14. Resulting Project Social Structure
SOFTWARE
MGMT.
AERO.
ELEC.
G & C
MFG.
COMM
PAYLOAD
I wonder when
they'll give us our
requirements?
9/22/2018
© USC-CSSE

15. History and Trends The waterfall model and its problems
Spiral model resolution of problems
Problems with spiral model
Initial resolution: win-win, anchor points
Further problems
Resolution with Incremental Commitment Model
9/22/2018
© USC-CSSE

16. DoDI 5000.2 “Spiral Development” Section 3.3.2.1
Desired capability is identified
End-state requirements not initially known
Requirements refined through demonstration and risk management
Continuous user feedback
Each increment provides user the best possible capability
Requirements for future increments depend on feedback from users and technology maturation
9/22/2018
© USC-CSSE

17. Spiral Model of Software Process7
9/22/2018
© USC-CSSE

18. Original Spiral and Misinterpretations
Common Misinterpretations
Hack some prototypes
Fit spiral into waterfall
Incremental waterfalls
Suppress risk analysis
No concurrency, feedback
One-size-fits-all model
9/22/2018
© USC-CSSE

19. What Is The Win Win Spiral Model?
A stakeholder-driven and risk-driven process model generator
There are no one-size-fits-all software process models
Different stakeholders and different risks generate different process models
A way to perform controlled concurrent engineering
Of systems and software; of development and evolution; of product and process
Controlled by anchor point milestones and Feasibility Rationales
An upward-compatible extension of the Rational Unified Process
Common risk and anchor-point orientation
With stakeholder and value-based extensions
Used successfully on a wide variety of applications
A way to implement DoDD and DoDI
9/22/2018
© USC-CSSE

20. The FCS Win-Win Spiral Model
Driven By:
Success-critical stakeholders’ win conditions
Progress Through Steps 2
1b. Stakeholders
Identify System
2a. Evaluate
Objectives, Constraints,
Alternatives
& Priorities (OC&Ps);
with respect to
Alternative Solution
OC&Ps
Elements
Risk Management 1 3
1a. Identify
2b.
Success-Critical
Assess,
Stakeholders
Address
Build 3
Build 2
Spiral anchor point milestones
Bl1
Stakeholders’
Risks
L CA
L CO 4 8
Commitment 7
Stakeholders’
Review 6
3. Elaborate
Product and
Feasibility Rationale
Process
4. Verify and Validate
Definition
Product and Process
Definitions 5
9/22/2018
© USC-CSSE

21. The WWSM Enables Concurrent Engineering
9/22/2018
© USC-CSSE

22. Spiral/MBASE/Rational Life-Cycle Model
Inception
Architectural prototype
Draft specifications & models
Elaboration
Initial executable system
Refined specifications & models R i s k
Construction
Iteration 3...
Intermediate system
Transition
Final system
Time
9/22/2018
© USC-CSSE

23. Continuous Integration Iterative Development
Project Results
Continuous Integration
Progress
(% coded)
Final Qual Test
Final Qual Test
100
Iterative Development
Demo 90
Integration Begins 80
Demo 70
Late Design
Breakage 60
Conventional 50
Demo 40 30 20 10
Time (months)
9/22/2018
© USC-CSSE

24. Experience with the Spiral Model
Good for getting risks resolved early
Good for tailoring process to situation
Good for accommodating COTS, reuse, prototyping
Where do objectives, constraints, and alternatives come from?
WinWin Negotiation and Maintenance of SCS WinWin (conditions)
Common life cycle milestones
Anchor Points
9/22/2018
© USC-CSSE

25. Life Cycle Anchor Points
Common System/Software stakeholder commitment points
Defined in concert with Government, industry affiliates
Coordinated with Rational’s Unified Software Development Process
Life Cycle Objectives (LCO)
Stakeholders’ commitment to support system architecting
Like getting engaged
Life Cycle Architecture (LCA)
Stakeholders’ commitment to support full life cycle
Like getting married
Initial Operational Capability (IOC)
Stakeholders’ commitment to support operations
Like having your first child
9/22/2018
© USC-CSSE

26. WinWin Spiral Anchor Point Milestone Content
(Risk-driven level of detail for each element)
*WWWWWHH: Why, What, When, Who, Where, How, How Much
Milestone Element
Life Cycle Objectives (LCO)
Life Cycle Architecture (LCA)
Definition of
Operational
Concept
Top-level system objectives and scope
- System boundary
- Environment parameters and assumptions
- Evolution parameters
Operational concept
- Operations and maintenance scenarios and parameters
- Organizational life-cycle responsibilities (stakeholders)
Elaboration of system objectives and scope of increment
Elaboration of operational concept by increment
Top-level functions, interfaces, quality attribute levels,
including:
- Growth vectors and priorities
- Prototypes
Stakeholders’ concurrence on essentials
Elaboration of functions, interfaces, quality attributes,
and prototypes by increment
- Identification of TBD’s( (to-be-determined items)
Stakeholders’ concurrence on their priority concerns
Top-level definition of at least one feasible architecture
- Physical and logical elements and relationships
- Choices of COTS and reusable software elements
Identification of infeasible architecture options
Choice of architecture and elaboration by increment
- Physical and logical components, connectors,
configurations, constraints
- COTS, reuse choices
- Domain-architecture and architectural style choices
Architecture evolution parameters
Elaboration of WWWWWHH* for Initial Operational
Capability (IOC)
- Partial elaboration, identification of key TBD’s for later
increments
Assurance of consistency among elements above
All major risks resolved or covered by risk management
plan
Identification of life-cycle stakeholders
- Users, customers, developers, maintainers, interoperators,
general public, others
Identification of life-cycle process model
- Top-level stages, increments
Top-level WWWWWHH* by stage
- via analysis, measurement, prototyping, simulation, etc.
- Business case analysis for requirements, feasible architectures
Definition of System
Requirements
and Software
Architecture
Definition of Life-
Cycle Plan
Feasibility
Rationale
System Prototype(s)
Exercise key usage scenarios
Resolve critical risks
Exercise range of usage scenarios
Resolve major outstanding risks
9/22/2018
© USC-CSSE

27. Pass/Fail Feasibility Rationales
Evidence provided by developer and validated by independent experts that:
If the system is built to the specified architecture, it will
Satisfy the requirements: capability, interfaces, level of service, AND evolution
Support the operational concept
Be buildable within the budges and schedules in the plan
Generate a viable return on investment
Generate satisfaction outcomes for all of the success-critical stakeholders
All major risks resolved or covered by risk management plans [mitigations]
Serves as basis for stakeholders’ commitment to proceed
9/22/2018
© USC-CSSE

28. Initial Operational Capability (IOC)
Software preparation
Operational and support software
Data preparation, COTS licenses
Operational readiness testing
Site preparation
Facilities, equipment, supplies, vendor support
User, operator, and maintainer preparation
Selection, teambuilding, training
9/22/2018
© USC-CSSE

29. Inception Elaboration Construction Transition Engineering Stage
Anchor Points and Rational USDP Phases
Engineering
Stage
Manufacturing
Stage
Inception
Elaboration
Construction
Transition
LCO
LCA
IOC
Feasibility
Iterations
Architecture
Iterations
Usable
Iterations
Product
Releases
Management R E Q D S I M P R E Q D E S I M P D E P R E Q D E S I M P D E P R E Q D E S I M P D E P
Management
Management
Management
RATIONAL
S o f t w a r e C o r p o r a t i o n
9/22/2018
© USC-CSSE

30. Spiral Anchor Points Enable Concurrent Engineering
9/22/2018
© USC-CSSE

31. History and Trends Outline
The waterfall model and its problems
Spiral model resolution of problems
Problems with spiral model
Initial resolution: win-win, anchor points
Further problems
Resolution with Incremental Commitment Model
9/22/2018
© USC-CSSE

32. Effect of Waterfall SEMP and Spiral SDP
Delays in starting critical software infrastructure
OS, networking, DBMS, transaction processing, …
Infeasible infrastructure
Premature performance requirements (e.g., 1 second)
Premature hardware selection overconstrains software
Can also induce premature COTS commitments
Waterfall-based progress payments undermine-spiral tasks
Develop prototypes or get paid for specifications
9/22/2018
© USC-CSSE

33. Further Problems with Spiral Model
Too easy to misinterpret
Propagated via vugraph vs. full paper
Concurrent, asynchronous, mini-spirals
Single, inexplicit role of risk
When, how to backtrack
When, how to skip cycles
9/22/2018
© USC-CSSE

34. Original Spiral and Misinterpretations
Common Misinterpretations
Unroll spiral into V-model
Hack some prototypes
Incremental waterfalls
Suppress risk analysis
No concurrency, feedback
One-size-fits-all model
9/22/2018
© USC-CSSE

35. “Spiral Model” – Example Misinterpretation From a government briefing “explaining” the spiral model Incremental, but no risk, concurrency, stakeholder satisficing
Requirements
Design
Implement
Test
9/22/2018
© USC-CSSE

36. Top-10 Risks: Software-Intensive Systems of Systems - CrossTalk, May 2004
Acquisition management and staffing
Requirements/architecture feasibility
Achievable software schedules
Supplier integration
Adaptation to rapid change
Quality factor achievability and tradeoffs
Product integration and electronic upgrade
Software COTS and reuse feasibility
External interoperability
Technology readiness
9/22/2018
© USC-CSSE

37. Effect of Software Underrepresentation
Software risks discovered too late
Slow, buggy change management
Recent large project reorganization
Software SW SW SW SW SW SW
9/22/2018
© USC-CSSE

38. Need for CRACK Integrated Team Members - CrossTalk, December 2003
Not Collaborative: Discord, frustration, loss of morale
Not Representative: Delivery of unacceptable systems, late rework
Not Authorized: Authorization delays, unsupported systems
Not Committed: Missing homework, discontinuities, delays
Not Knowledgeable: Unacceptable systems, delays, late rework
9/22/2018
© USC-CSSE

39. Supplier Integration: Rapid Adaptability to Change
Risk #4/5. Inflexible subcontracting will be a major source of delays and shortfalls.
Strategy #4/5. Develop subcontract provisions enabling flexibility in evolving deliverables. Develop an award fee structure based on objective criteria for:
- Schedule Preservation
- Cost Containment
- Technical Performance
- Architecture and COTS Compatibility
- Continuous Integration Support
- Program Management
- Risk Management
9/22/2018
© USC-CSSE

40. Top-10 Risks: Software-Intensive Systems of Systems - CrossTalk, May 2004
Acquisition management and staffing
Requirements/architecture feasibility
Achievable software schedules
Supplier integration
Adaptation to rapid change
Quality factor achievability and tradeoffs
Product integration and electronic upgrade
Software COTS and reuse feasibility
External interoperability
Technology readiness
9/22/2018
© USC-CSSE

41. Rapid, Synchronous Software Upgrades
Risk #7. Out-of-synchronization software upgrades will be a major source of operational losses
Software crashes, communication node outages, out-of-synch data, mistaken decisions
Extremely difficult to synchronize multi-version, distributed, mobile-platform software upgrades
Especially if continuous-operation upgrades needed
Strategy #7a. Architect software to accommodate continuous-operation, synchronous upgrades
E.g., parallel operation of old and new releases while validating synchronous upgrade
Strategy #7b. Develop operational procedures for synchronous upgrades in software support plans
Strategy #7c. Validate synchronous upgrade achievement in operational test & evaluation
9/22/2018
© USC-CSSE

42. COTS: The Future is Here
Escalate COTS priorities for research, staffing, education
It’s not “all about programming” anymore
New processes required
9/22/2018
© USC-CSSE

43. COTS Upgrade Synchronization and Obsolescence
Risk #8a: Many subcontractors means a proliferation of evolving COTS interfaces
Risk #8b: Aggressively-bid subcontracts can lead to delivery of obsolete COTS
New COTS released every 8-9 months (GSAW)
COTS unsupported after 3 releases (GSAW)
An actual delivery: 120 COTS; 46% unsupported
Strategy #8a: Emphasize COTS interoperability in source selection process
Strategy #8b: Contract provisions ensuring delivery of refreshed COTS products.
9/22/2018
© USC-CSSE

44. History and Trends Outline
The waterfall model and its problems
Spiral model resolution of problems
Problems with spiral model
Initial resolution: win-win, anchor points
Further problems
Resolution with Incremental Commitment Model
9/22/2018
© USC-CSSE

45. Problem Solutions: The Incremental Commitment Model
Use spiral principles vs. diagram
Relate to stakeholder commitments and values
Use multiple connected views
Make concurrency explicit
Use risk to show go-backs and skips
Provide view for handling mini-spirals
9/22/2018
© USC-CSSE

46. The Incremental Commitment Life Cycle Process: Overview
The Incremental Commitment Model (ICM) builds on concepts in the risk-driven spiral model [Boehm, 1988], the phases and anchor points in the Rational Unified Process (RUP) [Royce, 1998; Kruchten, 1999; Jacobson-Booch-Rumbaugh, 1999; Boehm, 1996], the Cooper stage-gate model [Cooper, 2001] and recent extensions of the spiral model to address systems of systems acquisition [Boehm, 2006]. In comparison to the software-intensive RUP, the ICM also addresses hardware and human factors integration. It extends the RUP phases to cover the full system life cycle: an Exploration phase precedes the RUP Inception phase, which is refocused on Valuation and investment analysis. The RUP Elaboration phase is refocused on Architecting; the RUP Construction and Transition phases are combined into Development; and an additional Operations phase combines operations, production, maintenance, and phase-out.
In comparison to the Cooper model, the ICM includes the Cooper Discovery and Scoping phases in Exploration; calls its Business Case phase Valuation; includes an Architecting phase not in Cooper; includes the Cooper Development and Test & Validation phases in Development; and extends the Cooper Launch phase to cover Operations.
In comparison to the V-model, the ICM explicitly emphasizes concurrent vs. sequential engineering of requirements and solutions, establishes explicit Feasibility Rationales as pass/fail milestone criteria, and provides explicit support for a stabilized current-increment development concurrently with a rebaselining activity to prepare for appropriate and stabilized development of the next increment.
Other aspects of the ICM and comparisons with process models are provided in the next charts.
9/22/2018
© USC-CSSE

47. Different Risks Create Different Processes
As can be seen by the four example paths through the Incremental Commitment Model, it is not a single monolithic one-size-fits-all process model. As with the spiral model, it is a risk-driven process model generator, but the ICM makes it easier to visualize how different risks create different processes.
In Example A, there is no need for a Valuation or Architecting activity if there is no risk that the ERP package will not support the application. Thus, an agile method such as a Scrum/Extreme Programming combination would be a good fit. There is no need for a Big Design Up Front (BDUF) because it is already present in the ERP package.
In Example B, one could use a sequential waterfall or V-model if its requirements were stable, the risks were low, and low cost were more important than a rapid development. Otherwise, a concurrent risk-driven waterfall or V-model that develops and reviews a Feasibility Rationale would be more appropriate.
In Example C, the stakeholders may have found during the Valuation phase that their original assumptions about the stakeholders having a clear, shared vision and compatible goals were optimistic. In such a case, it is better to go back and assure compatibility before proceeding.
In Example D, it is worth pointing out that it is not necessary to proceed to the next major milestone before terminating a clearly non-viable project.
9/22/2018
© USC-CSSE

48. The Incremental Commitment Life Cycle Process
The elaboration of the concurrent engineering and feasibility evaluation activities make it clearer just what is being concurrently engineered and evaluated in each phase. For example, at the Development Commitment Review, the stakeholders and specialty experts review the Life Cycle Architecture (LCA) package for the overall system and for each increment to assure themselves that it is worthwhile to commit their human, financial, or other resources to the system’s development. Charts 13 and 14 elaborate on the content of the LCA package and the Pass/Fail Feasibility Rationale used as a basis for acceptability. The next few charts provide complementary views of the Incremental Commitment Model that show further elaboration of its nature.
9/22/2018
© USC-CSSE

49. Stakeholder Commitment Ranges vs. Phase
Drivers
System Size
Length of Production Run
System Criticality
System Understanding Level
Stakeholder Compatibility
Personnel Capability
Amount of New Modeling/Infrastructure
The main point of this chart is to indicate that the relative resource commitment levels that stakeholders must furnish tend to increase with each successive phase, and that the commitments may be significant even in the early phases.
The placement of the boxes is based on rough engineering judgment. They are intended to represent rough 25th and 75th percentile ranges with respect to total resource commitment (in the software area, small (<10 people) projects account for about 60% of the projects, but large (>50 people) projects account for about 60% of the resources committed [Boehm-Turner, 2004]).
Factors causing resource commitment levels to be higher or lower include project size, length of production run, system criticality, system understanding level, stakeholder compatibility, personnel capability, and amount of new modeling and infrastructure capabilities needed.
9/22/2018
© USC-CSSE

50. Spiral Growth of System Understanding, Definition, and Commitment
Cumulative Level of Understanding, Cost, Time, Product and Process Detail (Risk-Driven)
Progress Through Steps
Evaluate alternatives, identify risks
Identify objectives, constraints, alternatives
Assess and mitigate risks
Identify, reconcile success-critical stakeholders’ win conditions
OCR3
OCR1
DCR1
ACR
ACR
DCR2
DCR3
Elaborate product and process
The spiral model provides another view of the incremental commitment process that reflects the continuing growth of systems understanding, system definition, and resource commitment. It also emphasizes the iterative nature of the process, in that each spiral cycle involves stakeholder satisficing, risk management, concurrent problem and solution definition, and solution feasibility analysis and review at increasing levels of detail. Consistently with chart 5, the spiral view does not imply a sequential progression, but emphasizes risk-driven concurrent mini-spirals, backtracking, or skipping of spiral cycles. Chart 22 provides a more detailed view of how various concurrent change-, risk-, or opportunity-driven mini-spirals would operate.
Anchor
point
commitment
milestones
Develop Feasibility Rationale
With concurrent mini-spirals
and backtracking
9/22/2018
© USC-CSSE

51. Risk-Driven Scalable Spiral Model: Increment View
9/22/2018
© USC-CSSE

52. Risk-Driven Scalable Spiral Model: Increment View
9/22/2018
© USC-CSSE

53. Risk-Driven Scalable Spiral Model: Life Cycle View
System
Inception
Elaboration
Agile DI2 (OO&D) Rebaselining
Plan-Driven DI1 Construction (A)
DI1 V&V
Plan-Driven DI2 Construction (A)
DI2 V&V
System LCA
System, DI1 LCA
DI2 B/L LCA
DI2 LCA
Changes
LCA: Life Cycle Architecture
IOC: Initial Operational Capability
OO&D: Observe, Orient and Decide
V&V: Verification and Validation
DI: Development Increment
B/L: Baselined
9/22/2018
© USC-CSSE

54. Risk-Driven Scalable Spiral Model: Life Cycle View
System
Inception
Elaboration
Agile DI2 (OO&D) Rebaselining
Plan-Driven DI1 Construction (A)
DI1 V&V
Agile DI3 (OO&D) Rebaselining
Plan-Driven DI2 Construction (A)
DI2 V&V
Agile DI4 (OO&D) Rebaselining
Plan-Driven DI3 Construction (A)
DI3 V&V
DI1 Trans’n
DI1 Usage
DI2 Trans’n
DI2 Usage
DI3 Trans’n
DI3 Usage
System LCA
DI3 LCA
System, DI1 LCA
DI2 B/L LCA
DI3 B/L LCA
DI4 B/L LCA
Update
DI2 LCA
Changes
DI4 LCA
. . .
DI1 IOC
DI3 IOC
DI2 IOC
LCA: Life Cycle Architecture
IOC: Initial Operational Capability
OO&D: Observe, Orient and Decide
V&V: Verification and Validation
DI: Development Increment
B/L: Baselined
9/22/2018
© USC-CSSE

55. Acquisition C4ISR Via Spiral OODA Loops
Observe new/updated objectives, constraints, alternatives
Usage monitoring
Competition, technology, marketplace ISR
Orient with respect to stakeholders priorities, feasibility, risks
Risk/Opportunity analysis
Business case/mission analysis
Prototypes, models, simulations
Operate as current system
Accept new system
Act on plans, specifications
Keep development stabilized
Change impact analysis, preparation for next cycle (mini-OODA loop)
Decide on next-cycle capabilities, architecture upgrades, plans
Stable specifications, COTS upgrades
Development, integration, V&V, risk management plans
Feasibility rationale
Life Cycle Architecture Milestone for Cycle
9/22/2018
© USC-CSSE

56. Agile Change Processing and Rebaselining
Stabilized
Increment-N
Development Team
Agile Future-
Increment
Rebaselining Team
Future Increment
Managers
Change
Proposers
Defer some Increment-N capabilities
Propose
Changes
Proposed changes
Recommend handling
in current increment
Assess Changes,
Propose Handling
Recommend no action,
provide rationale
Discuss, revise,
defer, or drop
Negotiate change
disposition
Handle in current rebaseline
Accept changes
Formulate, analyze options
in context of other changes
Handle
Accepted
Increment-N
changes
Recommend deferrals to future increments
Discuss, resolve deferrals to
future increments
Prepare for rebaselined
future-increment
development
Rebaseline
future-increment
LCA packages
9/22/2018
© USC-CSSE

57. Initial VBSE Theory: 4+1 Process – With a great deal of concurrency and backtracking
9/22/2018
© USC-CSSE

58. Frequent Protagonist Classes
Sierra Moutainbikes: Susan Swanson, new CEO
Bicycle champion, MBA, 15 years’ experience
Leads with goals, open agenda
9/22/2018
© USC-CSSE

59. Annual CrossTalk Top-5 Projects
Many candidate projects submitted annually
Providing evidence of success, key practices
Evaluated by leading software experts
Top-5 published in CrossTalk
DoD systems/software journal
20 projects to date: – 2005
9/22/2018
© USC-CSSE

60. Top-5 Use of Key Spiral Principles
Year
Concurrent Engineering
Risk-Driven
Evolutionary Growth
2002 4 3
2003 2
2004
2005 5
Total (of 20) 14 12
9/22/2018
© USC-CSSE

61. Spiral Aspects of CrossTalk 2002 Top-5 Software Projects
Degree
Concurrent
Requirements/
Solution Development
Risk – Driven
Activities
Evolutionary
Increment
Delivery
STARS Air Traffic Control *
Yes
HCI, Safety
For multiple sites
Minuteman III Messaging
(HAC/RMPE)
Safety
Yes; block
upgrades
FA-18 Upgrades
Not described
Census Digital Imaging
(DCS2000) **
No; fixed delivery
date
FBCB2 Army Tactical C3I
9/22/2018
© USC-CSSE

62. Spiral Aspects of CrossTalk 2003 Top-5 Software Projects
Degree
Concurrent
Requirements/
Solution Development
Risk – Driven
Activities
Evolutionary
Increment
Delivery
Defense Civilian Pay
(DCPS)
No; waterfall
Yes
For multiple organizations
Tactical Data Radio
(EPLRS) **
Joint Helmet-
Mounted Cueing
(JHMCS) *
Yes; IPT-based
Not described
For multiple aircraft
Kwajalein Radar
(KMAR)
For multiple radars
One SAF Simulation
Testbed (OTB)
9/22/2018
© USC-CSSE

63. Spiral Aspects of CrossTalk 2004 Top-5 Software Projects
Spiral Degree
Concurrent Requirements/ Solution Development
Risk – Driven Activities
Evolutionary Increment Delivery
Advanced Field Artillery (AFATDS)
Initially waterfall
Not described
Yes; block upgrades
Defense Medical Logistics (DMLSS)
F-18 HOL (H1E SCS)
Legacy requirements-driven
COTS, display No
One SAF Objectives System (OOS) **
Yes
Patriot Excalibur (PEX)
Yes; agile
9/22/2018
© USC-CSSE

64. Spiral Aspects of CrossTalk 2005 Top-5 Software Projects
Spiral Degree
Concurrent Requirements/ Solution Development
Risk – Driven Activities
Evolutionary Increment Delivery
Lightweight Handheld Fire Control **
Yes
Marines Integrated Pay (MCTFS)
Initially waterfall
Not described
Yes; block upgrades
Near Imaging Field Towers (NIFTI)
Yes; RUP based
Smart Cam Virtual Cockpit (SC3DF)
WARSIM Army Training
9/22/2018
© USC-CSSE

65. Conclusions
Defense and space systems undergoing transformation => Sw Intensive Systems of Systems (the transformer)
Need emphasis on spiral systems engineering principles => Incremental Commitment Model (ICM) for Systems
Need to integrate systems and software engineering => ICM for Sw Intensive Systems (SIS) & SIS of Systems
ICM (Spiral) approach enables concurrent engineering
And increased emphasis on risk (all kinds) management
New systems of systems risks emerging
And new mitigation approaches
And applied earlier (rapid adaptation of lessons learned)
CSSE is leading the field in addressing them
9/22/2018
© USC-CSSE

66. References
B. Boehm, W. Hansen, “The Spiral Model as a Tool for Evolutionary Acquisition,” Cross Talk, May 2001.
B. Boehm, D. Port, “Balancing Discipline and Flexibility with the Spiral Model and MBASE,” CrossTalk, December 2001, pp
B. Boehm et al., “Using the Win Win Spiral Model: A Case Study,” IEEE Computer, July 1998, pp
B. Boehm, D. Port, L. Huang, and W. Brown, “Using the Spiral Model and MBASE to Generate New Acquisition Process Models: SAIV/ CAIV, and SCQAIV,” CrossTalk, January 2002, pp
D. Reifer and B. Boehm, “A Model Contract/Subcontract Award Fee Plan for Large, Change-Intensive Software Acquisitions,” USC-CSE Technical Report, April 2003.
B. Boehm, A.W. Brown, V. Basili, and R. Turner, “Spiral Acquisition of Software-Intensive Systems of Systems,” Cross Talk, May 2004, pp. 4-9.
“Human-System Integration in the System Development Process: A New Look”, Report of the National Research Council of the National Acadamies, March 2007, National Academise Press (
MBASE web site : sunset.usc.edu/research/MBASE
Spiral/EA workshops web site :
CrossTalk articles:
9/22/2018
© USC-CSSE