Process Synchronization Workshop
Summary Report
Jo Ann Lane jolane@usc.edu
University of Southern California
Center for Software Engineering
© USC CSE 2008
Scope of
Process Synchronization Workshop
• Multi-owner System of Systems
• Agile/Plan-Driven
• Hardware and Software
Process Synchronization Workshop
© USC CSSE 2008
2
Workshop Issues, Goals, and Approach
• ICM provides a tailorable framework for SoSE, but
there are many devils in the details
• Key SoSE core elements are identified in the OUSD
AT&L SoS SE Guidebook [OUSD AT&L, 2008]
• Proposed workshop goals and approach
– Discuss SoSE core elements (chart #3) in context of SoSE
synchronization points (chart #6)
– Identify, prioritize key SoSE issues
– Discuss solution approaches for top-priority issues
– Evaluate degree of payoff, difficulty of solution approaches
on 0-10 scale
– Prepare summary briefing
Process Synchronization Workshop
© USC CSSE 2008
3
SoSE Core Elements*
Translating
Translating
Translating
capability
capability
objectives
capability
objectives
Assessing
Assessing
(actual)
Assessing
(actual)
performance
performance
performance
to
tocapability
capability
to
capability
objectives
objectives
objectives
objectives
Understanding
Understanding
systems
Understanding
systems&&
relationships
relationships
systems
&
(includes
plans)
(includes
plans)
relationships
Orchestrating
Orchestrating
Orchestrating
upgrades
upgrades
upgrades
to
toSoS
to SoS
SoS
Addressing
Addressing
Addressingnew
new
new
requirements
requirements
&&options
requirements
options
Developing,
Developing,
evolving
and
Developing
evolving
and
maintaining
maintaining
and
evolving
SoS
design/arch
SoS design/arch
SoS design
Typically not the
role of the SE but
key to SoS
[assumes these
are fixed]
Block upgrade
process for SoS
& solution options
Persistent
framework overlay
on systems in SoS
[architecture]
Monitoring
Monitoring
Monitoring
&&
assessing
assessing
&changes
assessing
changes
Large role of
external influences
changes
External Environment
* [OUSD AT&L, 2008]
Process Synchronization Workshop
© USC CSSE 2008
4
SoSE Synchronization Points:
Directed SoSs
ACR1
SoS-Level Exploration
Valuation
Candidate Supplier/
Strategic
Partner n
●
Source
Selection
Rebaseline/
Adjustment ACR1
DCR1
OCR1
Architecting
Develop
OCR2
Operation

LCO-type
Proposal &
Feasibility
Info
●
●
Candidate Supplier/
Strategic Partner 1
OCRx2
OCRx1
System x

Develop
OCRx3
Operation
Operation
OCRx5
OCRx4
Operation
Operation
DCRC
OCRC1

●
●
●
System C   
ACRC
Exploration
Valuation
Architecting
ACRB
System B   
Exploration
Valuation
   Exploration
Process Synchronization Workshop
Valuation
DCRB
Architecting
ACRA
System A
Develop
Operation
OCRB1
Develop
© USC CSSE 2008

OCRB2
Operation

OCRA1
DCRA
Architecting
OCRC2
Develop
Operation
5

SoSE Synchronization Points:
Acknowleged SoSs
ACR1
SoS-Level Exploration
Valuation
Candidate Supplier/
Strategic
Partner n
●
Source
Selection
Rebaseline/
Adjustment ACR1
DCR1
OCR1
Architecting
Develop
OCR2
Operation

LCO-type
Proposal &
Feasibility
Info
●
●
Candidate Supplier/
Strategic Partner 1
OCRx2
OCRx1
System x

Develop
OCRx3
Operation
Operation
OCRx5
OCRx4
Operation
Operation
DCRC
OCRC1

●
●
●
System C   
ACRC
Exploration
Valuation
Architecting
ACRB
System B   
Exploration
Valuation
   Exploration
Process Synchronization Workshop
Valuation
DCRB
Architecting
ACRA
System A
Develop
Operation
OCRB1
Develop
© USC CSSE 2008

OCRB2
Operation

OCRA1
DCRA
Architecting
OCRC2
Develop
Operation
6

Process Synchronization:
Summary of Discussions
•
Type of SoS impacts the amount of authority SoSE team has to control
synchronization of constituent systems
– Directed
• Responsibility and authority
• Synchronization accomplished via contracts
– Acknowledged
• Responsibility, but little or no authority
• Synchronization done through collaboration/negotiation /MOUs
between SoSE team and constituent systems
– Collaborative
• No authority, no responsibility at the SoS level
• Synchronization done through collaboration/negotiation /MOUs
between constituent systems
• Systems tend to know about each other
– Virtual
• Like collaborative, but systems don’t know about each other
Consider developing graphic that shows the continuum for the ICM guidebook
Process Synchronization Workshop
© USC CSSE 2008
7
Process Synchronization:
Summary of Discussions (continued)
• Hybrid Cases: SoS risk profiles and criticality may
indicate how SoS (or SoS parts) should be managed
(directed, acknowledged, collaborative)
– For example, a directed SoS may have non-critical parts that
are managed as an acknowledged or collaborative SoS
• Increment Scope: When planning SoS “increments”,
need to manage how much to SoS capability to
provide with respect to process capability
• Membership in Multiple SoSs: When constituent
systems are part of multiple SoSs, synchronization
within a given SoS can be difficult, if not impossible
Process Synchronization Workshop
© USC CSSE 2008
8
Process Synchronization Inhibitors
•
•
•
•
•
•
•
•
•
•
Lack of authority
Lack of funding
Legal/Congressional constraints impacting flexibility
Cultural constraints impacting flexibility
Contractual constraints/amount of time to change
contracts
Lack of insights into constituent system risks
Conflicting synchronization schedules
Conflicting goals and priorities of constituent systems
Language/terminology differences across systems
Control (or lack of control) over COTS vendors
Process Synchronization Workshop
© USC CSSE 2008
9
Candidate Actions to Minimize/Avoid
Synchronization Issues
• Level of authority should increase when current level of SoS
management is not working
– By putting an SoSE team in place (acknowledged or directed SoS),
team starts focusing on ConOps, SoS architecture, etc. as shown in
the Core Elements chart
• Pursue opportunities to identify, quantify, and mitigate risks
through the analysis of inter-system interactions and
dependencies
– More inter-system interactions and dependencies increase risk
• Migrate to an SoS architecture that is
– Logically loosely coupled
– Robust with respect to constituent system failure or degradation
– Conducive to individual system upgrades
• Investigate possibility of loosely coupled schedule (how tight
must it really be)
– Build in funded schedule margin
Process Synchronization Workshop
© USC CSSE 2008
10
Candidate Actions to Minimize/Avoid
Synchronization Issues (continued)
• Three areas to work
– Culture
– Process
– Tools
• Investigate possibility of a “blocking” policy to collect together
asynchronous updates and roll out together for situations where
synchronization is important
• Discover and encourage win-win conditions
– Need to “market”/explain advantages to suppliers why they
need to work to support SoS goals
Process Synchronization Workshop
© USC CSSE 2008
11
Conclusions
Synchronization may not be possible…
How to synchronize processes in an SoS
became
How to manage in the case where synchronization
is difficult or not possible
Need a better way to quantify and understand
interdependencies in both systems and SoSs and
determine how to best manage them
Process Synchronization Workshop
© USC CSSE 2008
12