USC
C S E
University of Southern California
Center for Software Engineering
Collaborative Design Workshop Overview
Barry Boehm, USC
CSSE Annual Research Review
February 12, 2007
USC
C S E
University of Southern California
Center for Software Engineering
Outline
• Participant introductions
• Future trends in software-intensive systems
• Proposed NSF Science of Design projects
– Medvidovic/Golubchik/Gupta HW-SW Design
– Boehm/Majchrzak/More Collaborative Design
• Interdisciplinary Collaborative Design
– Process context: Incremental Commitment Model
– Role of behavioral science concepts
• Boundary objects, transactive memory, guided discovery,
experiential learning
– Boundary objects in value-based design
• Lunch discussions
– Your best examples of boundary objects and usage
– What you’d most like to be able to do with boundary objects
02/12/07
©USC-CSE
2
USC
C S E
University of Southern California
Center for Software Engineering
Future Trends in Software-Intensive Systems
• Human-intensive, emergent
– Evolutionary, concurrent requirements and design process
• Rapid change; partly foreseeable
– Service-oriented framework for foreseeable aspects
– Encapsulated services for unforeseeable aspects
• Rapidly-formed, evolving global coalitions
– Friedman: The World is Flat
– SEI: Ultra Large Scale Systems
– Need rapid and effective teambuilding
02/12/07
©USC-CSE
3
USC
C S E
University of Southern California
Center for Software Engineering
Proposed NSF Science of Design Projects
• Medvidovic/Golubchik/Gupta: ArchitectureBased Multilevel Modeling
– Speed, power, reliability, …; gates  missions
• Boehm/Majchrzak/More: Interdisciplinary
Collaborative Design
– Integrating value-based design with behavioral
science concepts
• Boundary objects, transactive memory,
guided discovery, reciprocal learning
– Apply to experimental, observational testbeds
• IT Services Lab, industrial design, systems of
systems
02/12/07
©USC-CSE
4
USC
C S E
University of Southern California
Center for Software Engineering
The Incremental Commitment Model
• Provides context for what people from
different disciplines need to do
– To understand their options and their feasibility
wrt. other stakeholders’ value propositions
– To negotiate successful win-win agreements
– To determine when and how deeply to commit
resources
• Principles
• Phases and activity levels
• Details later
02/12/07
©USC-CSE
5
USC
University of Southern California
C S E
Center for Software Engineering
Incremental Commitment Model Principles
1.
2.
Success-critical stakeholder satisficing
Incremental growth of system definition
and stakeholder commitment
3,4. Concurrent, iterative system definition
and development cycles
Cycles can be viewed as sequential
concurrently-performed phases or spiral
growth of system definition
5.
Risk-based activity levels and anchor
point commitment milestones
02/12/07
©USC-CSE
6
USC
University of Southern California
C S E
Center for Software Engineering
Human-System Integration Levels of Activity:
Incremental Commitment Model (Part 1 of 2)
...
OCR2
DCR3
Operation1
Development2
Architecting3
OCR1
DCR2
DCR
Development1
Architecting2
ACR
Valuation
Exploration
HSI Activity
Category
VCR
Architecting
ECR
1. System Scoping
2. Understanding Needs
3. Envisioning Opportunities
4. Architecting and
Designing Solutions
4(a) Integration
4(b) Human Elements
4(c) Hardware Elements
4(d) Software Elements
5. Life Cycle Planning
6. Evaluation
02/12/07
©USC-CSE
7
USC
University of Southern California
C S E
Center for Software Engineering
Primary Focus of HSI Activity Categories - I
– HSI activities often span multiple categories
Activity
Category
System
Scoping
Understanding
Needs
Envisioning
Opportunities
Architecting
Solutions
- Integration
- Human
Elements
02/12/07
Primary Focus
Identifying current system shortfalls and ways of addressing
them via materiel or non-materiel solutions. Understanding
needs and envisioning opportunities as below. Establishing
initial system boundary that determines system scope.
Operations analysis, participatory analysis, ethnographic
analysis, success-critical stakeholder identification, MEAD,
social network analysis, competition analysis, market research,
future needs analysis
Scenarios, demonstrations, stories, shared visions, prototypes,
models; change monitoring (technology, competition,
marketplace, environment)
Architecture frameworks, COTS/reuse evaluation, legacy
transformation analysis, human/hardware/software allocation
and quality attribute analysis and synthesis
MEAD, participatory design, workflow/collaboration analysis
and synthesis, task/usability analysis and synthesis,
skill/career development planning
©USC-CSE
8
USC
C S E
University of Southern California
Center for Software Engineering
Outline
• Future trends in software-intensive systems
• Proposed NSF Science of Design projects
– Medvidovic/Golubchik/Gupta HW-SW Design
– Boehm/Majchrzak/More Collaborative Design
• Interdisciplinary Collaborative Design
– Process context: Incremental Commitment Model (ICM)
– Role of behavioral science concepts
• Boundary objects, transactive memory, guided discovery,
experiential learning
– Value-based boundary objects in ICM
• Lunch discussions
– Your best examples of boundary objects and usage
– What you’d most like to be able to do with boundary objects
02/12/07
©USC-CSE
9
USC
C S E
University of Southern California
Center for Software Engineering
Outline
• Future trends in software-intensive systems
• Proposed NSF Science of Design projects
– Medvidovic/Golubchik/Gupta HW-SW Design
– Boehm/Majchrzak/More Collaborative Design
• Interdisciplinary Collaborative Design
– Process context: Incremental Commitment Model (ICM)
– Role of behavioral science concepts
• Boundary objects, transactive memory, guided discovery,
experiential learning
– Value-based boundary objects in ICM
• Lunch discussions
– Your best examples of boundary objects and usage
– What you’d most like to be able to do with boundary objects
02/12/07
©USC-CSE
10
USC
C S E
University of Southern California
Center for Software Engineering
Incremental Commitment in Gambling
• Total Commitment: Roulette
– Put your chips on a number
– Wait and see if you win or lose
• Incremental Commitment: Poker, Blackjack
– Put some chips in
– See your cards, some of others’ cards
– Decide whether, how much to commit to proceed
02/12/07
©USC-CSE
11
USC
C S E
•
•
•
•
•
•
Incremental Commitment
In Life: Anchor Point Milestones
University of Southern California
Center for Software Engineering
Common System/Software stakeholder commitment points
– Defined in concert with Government, industry organizations
– Initially coordinated with Rational’s Unified Software
Development Process
Exploration Commitment Review (ECR)
– Stakeholders’ commitment to support initial system scoping
– Like dating
Validation Commitment Review (VCR)
– Stakeholders’ commitment to support system concept definition
and investment analysis
– Like going steady
Architecting Commitment Review (ACR)
– Stakeholders’ commitment to support system architecting
– Like getting engaged
Development Commitment Review (DCR)
– Stakeholders’ commitment to support system development
– Like getting married
Incremental Operational Capabilities (OCs)
– Stakeholders’ commitment to support operations
– Like having children
02/12/07
©USC-CSE
12
USC
C S E
University of Southern California
Center for Software Engineering
Exploration
Commitment
Review
DoD, General/DoD
Milestones
Valuation
Commitment
Review
Architecture
Commitment
Review
Development
Commitment
Review
VCR/
CD
ACR/A
DCR/B
ECR
Phases
(EVADO)
The Incremental Commitment
Life Cycle Process: Overview
Exploration
Valuation
Development1
Architecting2
Evaluation of Evidence
of Feasibility to
Proceed
Stakeholder Review
and Commitment
System
Architecting
High, but
Addressable
Acceptable
Risk?
Too High,
Unaddressable
DCR3/B3
Operations1
Operations2
Development2
Development3
Architecting3
Architecting4
Increment 1
Development
Increment 1
Operations
...
Increment 2
Architecting
Rebaseline
Increment 2
Development
...
Increment 3
Architecting
Rebaseline
...
...
Feasibility Rationales
OCR2/C2
DCR2/B2
Architecting
Concept
Definition,
Investment
Analysis
Initial Scoping
...
...
Acceptable
Acceptable
Acceptable
High, but
High, but
High, but
Addressable
Addressable
Addressable
Negligible
Risk?
Too High,
Unaddressable
Negligible
Risk?
Too High,
Unaddressable
Operations
Commitment
Review2
OCR1/C1
Activities
Concurrent Risk-andOpportunity-Driven
Growth of System
Understanding and
Definition
Operations
Commitment
Review1
Negligible
Risk?
Too High,
Unaddressable
Acceptable
High, but
Addressable
Negligible
Risk?
Negligible
Too High,
Unaddressable
Adjust Scope, Priorities, or Discontinue
02/12/07
©USC-CSE
13
USC
C S E
University of Southern California
Center for Software Engineering
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 successcritical stakeholders
• All major risks resolved or covered by risk
management plans
• Serves as basis for stakeholders’ commitment to
proceed
02/12/07
©USC-CSE
14
USC
C S E
Different Risks Create
Different Processes
University of Southern California
Center for Software Engineering
Operations1
A. Simple ERP-based application.
Development2
Development1
Exploration
Valuation ACR/A
VCR/
CD
High, but
Addressable
Acceptable
Acceptable
Risk?
Negligible
Architecting2
Architecting DCR/B
Risk?
Negligible
Risk?
OCR1/C1
Architecting3 OCR2/C2
DCR2/B2
DCR3/B3
...
Acceptable
Risk?
Acceptable
Risk?
Too High,
Unaddressable
B. Complex but feasible product development.
...
Acceptable
Risk?
Acceptable
Risk?
Acceptable
Risk?
Acceptable
Risk?
Acceptable
Risk?
C. Stakeholders agree that more convergence of objectives is necessary.
...
Acceptable
Risk?
High, but
addressable
Acceptable
Risk?
Acceptable
Acceptable
Acceptable
Risk?
Risk?
Risk?
Risk?
Risk?
Risk?
D. A superior product enters the marketplace.
Acceptable
Risk?
Acceptable
Risk?
Too high,
unaddressable
Discontinue
02/12/07
©USC-CSE
15
USC
C S E
University of Southern California
Center for Software Engineering
Value-Based Boundary Objects
• Context: Incremental Commitment Model
– Model and boundary objects evolved over 10 years of annual eservices projects, systems of systems support activities
• Some value-based boundary objects
–
–
–
–
–
–
Getting started: Spiderweb diagram
Shared vision: scenarios, stories, prototypes
Identifying added initiatives, stakeholders: Benefits Chain
Avoiding overkill: Simplifiers and complicators; cost models
Negotiating requirements: EasyWinWin tool
Understanding solutions: workflows, designs, plans
• Experimental research example
– WikiWinWin tool
02/12/07
©USC-CSE
16
USC
University of Southern California
C S E
Center for Software Engineering
The Model-Clash Spider Web: Master Net
- Stakeholder value propositions (win conditions)
02/12/07
©USC-CSE
17
USC
C S E
University of Southern California
Center for Software Engineering
The Information Paradox (Thorp)
• No correlation between companies’ IT investments
and their market performance
• Field of Dreams
– Build the (field; software)
– and the great (players; profits) will come
• Need to integrate software and systems initiatives
02/12/07
©USC-CSE
18
USC
C S E
University of Southern California
Center for Software Engineering
DMR/BRA* Results Chain
Order to delivery time is
an important buying criterion
INITIATIVE
Contribution
Implement a new order
entry system
ASSUMPTION
OUTCOME
Contribution
OUTCOME
Reduced order processing cycle
(intermediate outcome)
Increased sales
Reduce time to process
order
Reduce time to deliver product
*DMR Consulting Group’s Benefits Realization Approach
02/12/07
©USC-CSE
19
USC
C S E
University of Southern California
Center for Software Engineering
Expanded Order Processing System Benefits Chain
Distributors, retailers,
customers
Assumptions
- Increasing market size
- Continuing consumer satisfaction with product
- Relatively stable e-commerce infrastructure
- Continued high staff performance
New order-entry
system
Developers
Less time,
fewer
errors per
order
entry
system
Safety, fairness
inputs
Less time, fewer
errors in order
processing
Faster,
better
order
entry
system
Interoperability
inputs
Increased
customer
satisfaction,
decreased
operations costs
Faster order-entry steps, errors
On-time assembly
New order-entry
processes,
outreach, training
Improved supplier
coordination
Sales personnel,
distributors
02/12/07
New order fulfillment
processes,
outreach, training
New order fulfillment
system
©USC-CSE
Increased
sales,
profitability,
customer
satisfaction
Increased profits,
growth
Suppliers
20
USC
University of Southern California
C S E
Center for Software Engineering
Conflicts in Win Conditions and Expectations
•Hard things for software people
“If you can do queries with all those ands, ors, synonyms, data
ranges, etc., it should be easy to do natural language queries.”
“If you can scan the document and digitize the text, it should be
easy to digitize the figures too.”
•Hard things for clients
“It was nice that you could add this access feature, but it overly
(centralizes, decentralizes) control of our intellectual property
rights.”
“It was nice that you could extend the system to serve the medical
people, but they haven’t agreed to live with our usage guidelines.”
02/12/07
©USC-CSE
21
USC
C S E
University of Southern California
Center for Software Engineering
S&C Subdomain (General)
Type of
Application
Simple Block Diagram
query
Multimedia
Archive
Catalog
update
notification
query
update
MM asset
info
MM
Archive
Examples
(project nos.)
1, 3, 4, 5,
6, 7, 8, 9,
10, 11, 12,
13, 14, 15,
20, 31, 32,
35, 36, 37,
39



Deveoper
Simplifiers
Use standard
query languages
Use standard or
COTS search
engine
Uniform media
formats




MM asset




02/12/07
©USC-CSE
Developer
Complicators
Natural language
processing
Automated
cataloging or
indexing
Digitizing large
archives
Digitizing
complex or fragile
artifacts
Rapid access to
large Archives
Access to
heterogeneous
media collections
Automated
annotation/descrip
tion/ or meanings
to digital assets
Integration of
legacy systems
22
USC
C S E
University of Southern California
Center for Software Engineering
EasyWinWin OnLine Negotiation Steps
02/12/07
©USC-CSE
23
USC
C S E
University of Southern California
Center for Software Engineering
Red cells indicate lack of
consensus.
Oral discussion of cell
graph reveals unshared
information, unnoticed
assumptions, hidden
issues, constraints, etc.
02/12/07
©USC-CSE
24
t
USC
C S E
University of Southern California
Year 1
Center for Software Engineering
Year 2
Year 3
NSF Science of Design Research Plan
1. Empirical Analysis of Industry
Use of Boundary Objects (BOs)
– More, Majchrzak
Analysis of current use, critical
success
factors,
propositions,
moderators.
Define, prepare for pilots.
Run pilots, analyze results, suggest
TPPT improvements.
Prepare, train for Interventions.
Run Interventions, analyze results.
Suggest TPPT improvements.
2. Development, Refinement of BO
Usage Theory, Principles, Practices,
and Tools (TPPTs)
– Majchrzak, More, Boehm
Use
propositions,
moderators,
analyses to develop and refine BO
TPPTs.
Integrate results of pilots with
respect to BO TPPTs.
Develop BO TPPT improvements.
Integrate results of Interventions
with respect to BO TPPTs.
Develop BO TPPT improvements.
3.Integrated VB/BO TPPTs
- All
Integrate, evaluate, refine VB/BO theory, principles, practices, and tools
Broaden dissemination of results.
4. Integration of BOs into ValueBased (VB) TPPTs
-Boehm, Majchrzak, More, RA’s
Use
propositions,
moderators,
analyses to create BO extension to
VB TPPTs.
Integrate results of pilots with
respect to VB TPPTs.
Develop VB TPPT improvements.
Integrate results of Interventions
with respect to VB TPPTs.
Develop VB TPPT improvements.
5. Empirical Analysis of IT Services
Use of BO’s
-Boehm,
Majchrzak,
Koolmanojwong,Wu
Analysis of current use, critical
success
factors,
propositions,
moderators.
Define, prepare for pilots.
Run pilots, analyze results, suggest
TPPT improvements.
Prepare, train for Interventions.
Run Interventions, analyze results.
Suggest TPPT improvements.
6. Empirical Analysis of Systems of
Systems
Use of BOs
-Boehm, Lane, Ingold
Analysis of current use, critical
success
factors,
propositions,
moderators.
Define, prepare for pilots.
Run pilots, analyze results, suggest
TPPT improvements.
Prepare, train for Interventions.
Run Interventions, analyze results.
Suggest TPPT improvements.
02/12/07
©USC-CSE
25
USC
C S E
University of Southern California
Center for Software Engineering
WikiWinWin: Majchrzak Research
• Wikis can strongly facilitate collaboration
– Low entry barrier, flexible usage
• “Shapers” a critical success factor
– Focus on reorganizing vs. adding group knowledge
– Example of a shaper: Howard
•75-person software engineering group at a multi-billion dollar tech
company
•“I spend up to two hours a day working on the wiki. Much of this time I
reorganize other people’s materials, rename pages, create new links on
the home page, or restructure the home page. Benefits aren’t to mean
personally, but they help the group collaborate more effectively. They
can find things easier”
02/12/07
©USC-CSE
26
USC
C S E
University of Southern California
Center for Software Engineering
EasyWinWin Strengths and Difficulties
• Strengths
– Group-oriented brainstorming, prioritization
– Clear progression toward win-win equilibrium
• Difficulties
– Overly sequential progression toward win-win equilibrium
– Timeconsuming group shaping
• Resolving duplicates, overlaps; categorizing
– Outdated, unsupported infrastructure
• Primary tool expert graduating
02/12/07
©USC-CSE
27
USC
C S E
University of Southern California
Center for Software Engineering
WikiWinWin Approach to Team Projects
• Explain approach to clients
• Select 1-2 team members as overall shapers
– Anyone can contribute to shaping
• Provide class lecture, developer-client tutorial
• Establish preconditions for use
– Majchrzak teamforming session; client site visit, early
shared vision interactions, concurrent prototyping plans
• At least initial collocated, facilitated sesssion
• Prestructured but modifiable areas provided
– Negotiation topics, issue identification and resolution,
feature prioritization, definition of terms, …
– Evaluate prestructuring, flexibility effects
02/12/07
©USC-CSE
28
USC
C S E
University of Southern California
Center for Software Engineering
Outline
• Future trends in software-intensive systems
• Proposed NSF Science of Design projects
– Medvidovic/Golubchik/Gupta HW-SW Design
– Boehm/Majchrzak/More Collaborative Design
• Interdisciplinary Collaborative Design
– Process context: Incremental Commitment Model
– Role of behavioral science concepts
• Boundary objects, transactive memory, guided discovery,
experiential learning
– Boundary objects in value-based design
• Lunch discussions
– Your best examples of boundary objects and usage
– What you’d most like to be able to do with boundary objects
02/12/07
©USC-CSE
29
USC
C S E
University of Southern California
Center for Software Engineering
Backup Charts
USC
C S E
Spiral Anchor Points
Enable Concurrent Engineering
University of Southern California
Center for Software Engineering
I
R
R
02/12/07
L
C
O
L
C
A
©USC-CSE
C
C
D
I
O
C
P
R
R
31
USC
C S E
University of Southern California
Center for Software Engineering
Stakeholder Commitment
Ranges vs. Phase
1000
300
Relative
Commitment
Level
100
30
10
3
Drivers
System Size
1
Length of Production Run
System Criticality
System Understanding Level
Stakeholder Compatibility
Personnel Capability
Amount of New Modeling/Infrastructure
02/12/07
E
V
A
D
O
Phase
©USC-CSE
32
USC
University of Southern California
C S E
Center for Software Engineering
Exploration
Commitment
Anchor Point
Review
Milestones/
DoD Acquisition
ECR
Milestones
Phases
(EVADO)
The Incremental Commitment
Life Cycle Process
Valuation
Commitment
Review
Architecting
Commitment
Review
Development
Commitment
Review
VCR/
CD
ACR/A
DCR/B
Exploration
Valuation
Architecting
Activities
Concurrent Risk-andOpportunity-Driven
Growth of System
Understanding and
Definition
Evaluation of Evidence of
Feasibility to Proceed
Stakeholder Review and
Commitment
Exploration and initial
scoping of technical,
economic,
sociopolitical, and
managerial aspects
of new initiative
Definition and
analysis of scope and
solution alternatives






Environment
Competition
Mission needs
Stakeholder
readiness
Acceptable
Risk?
Too High,
Unaddressable
OCR1/C1
OCR2/C2
DCR2/B2
DCR3/B3
Development1
Operations1
Operations2
Architecting2
Development2
Development3
Architecting3
Architecting4
Use LCA1 Package
for stabilized
development, V&V of
Increment 1
Use LCA2 Package
for stabilized
development, V&V of
Increment 2
COTS, outsource
partner selections
Concurrent, agile
change processing,
rebaselining of
LCA2,… LCAN
packages
Concurrent, agile
change processing,
rebaselining of
LCA3,… LCAN
packages
Increment1 readiness
for operations; LCA2
feasibility
Detailed feasibility
rationale, business
case
Increment2 readiness
for operations; LCA3
feasibility
Acceptable
Acceptable
Acceptable
High, but
High, but
High, but
Addressable
Addressable
Addressable
Negligible
Risk?
Too High,
Unaddressable
Negligible
...
Operations and
usage monitoring of
Increment 1
Detailed ops concept,
requirements,
architecture, plans
(System, increment
Life Cycle
Architecture
packages)
Top-level feasibility
rationale, trade
studies, business
case
Operations
Commitment
Review2
Detailed mission
scenarios, business
work flows, macroergonomics aspects
System/human/
hardware/software
build-to architecture
Top-level ops
concept,
requirements,
architecture, life cycle
plans
Ethnographic,
operations analysis,
models, simulations,
prototypes
High, but
Addressable
Human,
hardware,
software factors
Mission
analyses,
business cases
Operations
Commitment
Review1
Risk?
Too High,
Unaddressable
Negligible
Risk?
...
Acceptable
High, but
Addressable
Negligible
Too High,
Unaddressable
Risk?
Too High,
Unaddressable
Acceptable
High, but
Addressable
Negligible
Risk?
Negligible
Too High,
Unaddressable
Adjust Scope, Priorities, or Discontinue
02/12/07
©USC-CSE
33
USC
C S E
University of Southern California
Center for Software Engineering
Risk-Driven Scalable Spiral Model:
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/12/07
©USC-CSE
34
USC
C S E
University of Southern California
Center for Software Engineering
Risk-Driven Scalable Spiral Model:
Increment View
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
02/12/07
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
©USC-CSE
35
USC
C S E
University of Southern California
Center for Software Engineering
Risk-Driven Scalable Spiral Model:
Life Cycle View
System LCA
System
Inception
System, DI1 LCA
System
Elaboration
DI2 B/L LCA
Changes
Agile DI2 (OO&D)
Rebaselining
Plan-Driven DI1
Construction (A)
DI1 V&V
Plan-Driven DI2
Construction (A)
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
02/12/07
DI2 LCA
DI2 V&V
©USC-CSE
36
USC
University of Southern California
C S E
Center for Software Engineering
Risk-Driven Scalable Spiral Model:
Life Cycle View
System LCA System, DI1 LCA
System
Inception
DI2 B/L LCA
DI3 B/L LCA
DI4 B/L LCA
Changes
System
Elaboration
Agile DI2 (OO&D)
Rebaselining
Plan-Driven DI1
Construction (A)
DI1 V&V
Changes
Update
Update
DI1 IOC
DI1
Trans’n
DI1
Usage
DI2 LCA
Agile DI3 (OO&D)
Rebaselining
Plan-Driven DI2
Construction (A)
DI2 V&V
Changes
Update
DI2 IOC
DI2
Trans’n
DI2
Usage
DI3 LCA
Agile DI4 (OO&D)
Rebaselining
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
02/12/07
Plan-Driven DI3
Construction (A)
DI3 V&V
DI3 IOC
DI3
Trans’n
DI3
Usage . . .
DI4 LCA
...
©USC-CSE
37
USC
C S E
University of Southern California
Center for Software Engineering
Acquisition C4ISR Via Spiral OODA Loops
Observe new/updated objectives,
Orient with respect to stakeholders
• Usage monitoring
• Risk/Opportunity analysis
• Competition, technology,
marketplace ISR
• Business case/mission analysis
constraints, alternatives
priorities, feasibility, risks
• Prototypes, models, simulations
Operate as current system
Accept new system
Decide on next-cycle capabilities,
Act on plans, specifications
architecture upgrades, plans
• Keep development stabilized
• Stable specifications, COTS
upgrades
• Change impact analysis,
preparation for next cycle (miniOODA loop)
• Development, integration, V&V, risk
management plans
• Feasibility rationale
Life Cycle Architecture Milestone for Cycle
02/12/07
©USC-CSE
38
USC
Agile Change Processing
and Rebaselining
University of Southern California
C S E
Center for Software Engineering
Stabilized
Increment-N
Development Team
Agile FutureIncrement
Rebaselining Team
Future Increment
Managers
Change
Proposers
Proposed changes
Propose
Changes
Defer some Increment-N capabilities
Recommend handling
in current increment
Negotiate change
disposition
Accept changes
Handle
Accepted
Increment-N
changes
Assess Changes,
Propose Handling
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
LCA packages
02/12/07
Recommend no action,
provide rationale
©USC-CSE
Prepare for rebaselined
future-increment
development
39
USC
University of Southern California
C S E
Center for Software Engineering
Initial VBSE Theory: 4+1 Process
– With a great deal of concurrency and backtracking
5a, 7b. Option, solution
development & analysis
Dependency
Theory
Utility Theory
2a. Results Chains
2. Identify SCSs
3b, 5a, 7b. Cost/schedule/
performance tradeoffs
3b, 7a. Solution Analysis
3. SCS Value
Propositions
(Win conditions)
4. SCS expectations
management
Theory W:
SCS Win-Win
6, 7c. Refine, Execute,
Monitor & Control Plans
Control Theory
5a, 7b. Prototyping
5. SCS Win-Win
Negotiation
1. Protagonist goals
3a. Solution exploration
7. Risk, opportunity, change
Decision Theory
management
6a, 7c. State measurement,
prediction, correction;
Milestone synchronization
5a. Investment analysis,
Risk analysis
SCS: Success-Critical Stakeholder
02/12/07
©USC-CSE
40
USC
C S E
University of Southern California
Center for Software Engineering
Frequent Protagonist Classes
Protagonist Class
Goals
Authority
Ideas
Resources
Leader with Goals, Baseline Agenda
X
X
X
X
Leader with Goals, Open Agenda
X
X
Entrepreneur with Goals, Baseline
Agenda
X
Entrepreneur with Goals, Open Agenda
X
Inventor with Goals, Ideas
X
Consortium with Shared Goals
X
X
X
X
X
X
(X)
(X)
•Sierra Moutainbikes: Susan Swanson, new CEO
– Bicycle champion, MBA, 15 years’ experience
– Leads with goals, open agenda
02/12/07
©USC-CSE
41
USC
C S E
University of Southern California
Center for Software Engineering
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
– http://www.stsc.hill.af.mil/crosstalk
– 20 projects to date: 2002 – 2005
02/12/07
©USC-CSE
42
USC
University of Southern California
C S E
Center for Software Engineering
Top-5 Use of Key Spiral Principles
Year
Concurrent
Engineering
2002
2003
4
4
3
3
3
2
2004
2005
Total (of 20)
2
4
14
2
4
12
2
5
12
02/12/07
Evolutionary
Risk-Driven
Growth
©USC-CSE
43
USC
C S E
University of Southern California
Center for Software Engineering
Spiral Aspects of CrossTalk 2002
Top-5 Software Projects
Spiral
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)
*
Yes
Safety
Yes; block
upgrades
FA-18 Upgrades
*
Not described
Yes
Yes; block
upgrades
Census Digital
Imaging
(DCS2000)
**
Yes
Yes
No; fixed
delivery
date
FBCB2 Army
Tactical C3I
**
Yes
Yes
Yes
02/12/07
©USC-CSE
44
USC
C S E
University of Southern California
Center for Software Engineering
Spiral Aspects of CrossTalk 2003 Top-5
Software Projects
Spiral
Degree
Defense Civilian
Pay
(DCPS)
Concurrent
Requirements/
Solution Development
Risk – Driven
Activities
No; waterfall
Yes
Yes
Evolutionary
Increment
Delivery
For multiple
organization
s
Tactical Data
Radio
(EPLRS)
**
Yes
Joint HelmetMounted Cueing
(JHMCS)
*
Yes; IPT-based
Not
described
For multiple
aircraft
Kwajalein Radar
(KMAR)
*
Yes; IPT-based
Not
described
For multiple
radars
One SAF
Simulation
Testbed (OTB)
**
Yes
02/12/07
©USC-CSE
Yes
Yes
Yes
45
USC
C S E
University of Southern California
Center for Software Engineering
Spiral Aspects of CrossTalk 2004
Top-5 Software Projects
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)
Initially waterfall
Not
described
Yes; block
upgrades
Legacy
requirementsdriven
COTS,
display
No
Spiral
Degree
F-18 HOL (H1E
SCS)
One SAF
Objectives
System (OOS)
**
Yes
Yes
Yes
Patriot Excalibur
(PEX)
**
Yes; agile
Not
described
Yes
02/12/07
©USC-CSE
46
USC
C S E
University of Southern California
Center for Software Engineering
Spiral Aspects of CrossTalk 2005
Top-5 Software Projects
Lightweight
Handheld Fire
Control
Spiral
Degre
e
Concurrent
Requirements/
Solution
Development
Risk –
Driven
Activities
Evolutionary
Increment
Delivery
**
Yes
Yes
Yes
Initially waterfall
Not
described
Yes; block
upgrades
Marines Integrated
Pay (MCTFS)
Near Imaging Field
Towers (NIFTI)
**
Yes; RUP based
Yes
Yes
Smart Cam Virtual
Cockpit (SC3DF)
**
Yes
Yes
Yes
WARSIM Army
Training
**
Yes
Yes
Yes
02/12/07
©USC-CSE
47