University of Southern California
Center for Systems and Software Engineering
System of Systems Engineering
Cost Modeling:
Strategies for Different Types of
Systems of Systems
Jo Ann Lane
USC CSSE
jolane@usc.edu
COCOMO Forum
October 2008
University of Southern California
Center for Systems and Software Engineering
Overview
•
•
•
•
Key definitions
Model implementation
Results of research
Conclusions and future work
October 2008
©USC-CSSE
2
University of Southern California
Center for Systems and Software Engineering
What is a “System of Systems”?
• Very large systems developed by creating a framework or
architecture to integrate constituent systems
• SoS constituent systems independently developed and managed
–
–
–
–
New or existing systems in various stages of development/evolution
May include a significant number of COTS products
Have their own purpose
Can dynamically come and go from SoS
• SoS exhibits emergent behavior not otherwise achievable by
component systems
• Typical domains
– Business: Enterprise-wide and cross-enterprise integration to
support core business enterprise operations across functional and
geographical areas
– Military: Dynamic communications infrastructure to support
operations in a constantly changing, sometimes adversarial,
environment
Based on Mark Maier’s SoS definition [Maier, 1998]
October 2008
©USC-CSSE
3
University of Southern California
Center for Systems and Software Engineering
Related Engineering Disciplines
• SoSE
– Term primarily used within DoD to describe engineering activities associated
with the development and enhancement of SoS capabilities
• COTS integration
– Special case of SoSE where constituent systems are primarily commercial
products, often from different vendors
• Enterprise-wide systems engineering
– Special case of SoSE where constituent systems primarily support business
functions
• May include both COTS and legacy (custom) systems
• Typically “owned” by the enterprise
• May include manufacturing and supply chain operations
• IT Outsourcing
– An approach to enterprise-wide engineering where the engineering activities
are outsourced to another organization
– Typically includes some combination of systems engineering, software
development, system operation and administration, and business support
October 2008
©USC-CSSE
4
University of Southern California
Center for Systems and Software Engineering
Types of SoS
•
Virtual [Maier, 1998]
– Lacks a central management authority and a clear SoS purpose
– Often ad hoc and may use a service-oriented architecture where
the constituent systems are not necessarily known
•
Collaborative [Maier, 1998]
– Constituent system engineering teams work together more or less
voluntarily to fulfill agreed upon central purposes
– No SoSE team to guide or manage activities of constituent systems
•
Acknowledged [Dahmann, 2008]
– Have recognized objectives, a designated manager, and resources
at the SoS level (SoSE team)
– Constituent systems maintain their independent ownership,
objectives, funding, and development approaches
•
Research
focusing on
identifying the
“homeground” for
these two
types of
SoSs...
Directed [Maier, 2008]
– SoS centrally managed by a government, corporate, or Lead
System Integrator (LSI) and built to fulfill specific purposes
– Constituent systems maintain ability to operate independently, but
evolution subordinated to centrally managed purpose
October 2008
©USC-CSSE
5
University of Southern California
Center for Systems and Software Engineering
SoS System Interdependency
Process Model Overview
•
Purpose
– Estimate and compare the effort required to implement an SoS
capability using two different management approaches
• Collaborative (no SoSE team)
• Acknowledged (SoSE with limited authority/control)
•
Assumptions and constraints
– All constituent systems currently exist and have their own evolutionary
paths based on system-level stakeholder needs/desires
– Model assumes SoSE and traditional SE teams are using relatively
mature processes
– SoS capabilities are software-intensive
– No SoS requirements volatility
– No accommodation of schedule factors or the asynchronous nature of
SoS constituent system upgrades
– Management of SoS internal interfaces reduces complexity for systems
– SE effort/information provided to SoSE team in support of SoSE must be
added to SE effort for the part of the upgrade requirements that are at
the SoS level
October 2008
©USC-CSSE
6
University of Southern California
Center for Systems and Software Engineering
Systems Engineering Requirements Categories
•
Requirements related to SoS capabilities
a) Acknowledged SoS: Initially engineered at SoS level by SoSE
team with support from constituent system engineers for
those systems impacted by the SoS capability, then allocated
to constituent systems for further SE
b) Collaborative SoS: Not engineered at the SoS level, but must
be engineered fully at the constituent system level through
collaborative efforts with other constituent system engineers
•
Non-SoS requirements related to constituent system
stakeholder needs
– Must be monitored or “managed” by SoSE team to identify
changes that might adversely impact SoS
– Represents on-going volatility at the constituent system level
that is occurring in parallel with SoS capability changes
October 2008
©USC-CSSE
7
University of Southern California
Center for Systems and Software Engineering
SoS System Interdependency Model Structure
Focus is on softwareintensive SoSs
owned by the US
DoD, the number and
volatility of
constituent systems
within an SoS, and
the complexity of
typical capability
enhancements to the
SoS...
Complexity
Factors
COSYSMO
EMs
October 2008
©USC-CSSE
8
University of Southern California
Center for Systems and Software Engineering
Model Parameters
•
•
Stocks
– Inputs
• SoS Equivalent
Requirements
– Outputs (interim and final)
• SoSE Effort
• SoS Upgrade Effort with
SoSE
• SoS Upgrade Effort without
SoSE
•
Flows
–
–
–
–
Capability Rate
SoSE Effort Rate
SE Effort Rate with SoSE
SE Effort Rate without SoSE
October 2008
Converter Parameters
– COSYSMO effort multipliers (EMs)
• COSYSMO SoSE EM
• COSYSMS SoSE “Managed”
EM
• COSYSMO SE EM with SoSE
• COSYSMO SE EM without
SoSE
• COSYSMO SE EM
– SoS complexity factors
• Number of systems in SoS
• Number of systems affected by
capability
• Average system rate of change
©USC-CSSE
9
University of Southern California
Center for Systems and Software Engineering
SoSE EM
October 2008
©USC-CSSE
10
University of Southern California
Center for Systems and Software Engineering
EM for SoSE “Managed” Requirements
October 2008
©USC-CSSE
11
University of Southern California
Center for Systems and Software Engineering
SE EM for SoS Requirements with SoSE Support
October 2008
©USC-CSSE
12
University of Southern California
Center for Systems and Software Engineering
SE EM SoS Requirements without SoSE Support
October 2008
©USC-CSSE
13
University of Southern California
Center for Systems and Software Engineering
SE EM for System-Specific (Non-SoS) Requirements
October 2008
©USC-CSSE
14
University of Southern California
Center for Systems and Software Engineering
Effort Calculations
SoSE Effort
SoSE Effort = 38.55*[((SoSCR/SoSTreq)*(SoSTreq)1.06 *EMSoS-CR)+
((SoSMR/SoSTreq)*(SoSTreq)1.06 * EMSoS-MR)/152]
Where:
Total SoSE requirements = SoS Capability Requirements + SoS “Managed” Requirements
SoS “managed” reqs = [∑SE non-SoS requirements being addressed current upgrade cycles for
all SoS constituent systems] * “managed reuse factor”
“Managed reuse factor” = 15.4%
Based on COCOMO II approach for combining components with different
EMs (SoS changes and Constituent System “managed” oversight)...
October 2008
©USC-CSSE
15
University of Southern California
Center for Systems and Software Engineering
Effort Calculations (continued)
Single System Effort with Support from SoSE Team
Total single system reqsw-SoSE = SoS requirements allocated to system + SE reqs in
upgrade cycle
Single system SE Effort with SoSE Team
= 38.55*[1.15*( (SoSCSalloc / CSTreqSoSE)*( CSTreqSoSE)1.06* EMCS-CRwSOSE) +
(CSnonSoS / CSTreqSoSE)*( CSTreqSoSE)1.06* EMCSnonSOS] /152
Based on COCOMO II approach for combining components with different
EMs plus including a 15% “tax” to support SoSE team in their engineering
effort for the SoSE requirements. 15% represents half of the system design
effort in the EIA 632 tasks.
October 2008
©USC-CSSE
16
University of Southern California
Center for Systems and Software Engineering
Effort Calculations (continued)
Single System Effort with No SoSE Team Support
Total single system reqs wo-SoSE = SoSE capability reqs + SE non-SoS requirements
Single system SE Effort without SoSE Team =
38.55*[(( SoSCR / CSTreqwoSoSE)*( CSTreqwoSoSE)1.06* EMCS-CRnSOSE) +
((CSnonSoS / CSTreqwoSoSE)*( CSTreqwoSoSE)1.06* EMCSnonSOS)] /152
Based on COCOMO II approach for combining components
with different EMs (SoS changes and non-SoS changes)...
October 2008
©USC-CSSE
17
University of Southern California
Center for Systems and Software Engineering
Sample Results
Relative Cost of Collaborative and Acknowledged SoSE
Capability Affects Half of the Systems
System Volatility = 100 Reqs and SoS Capability = 100 Reqs
Relative Cost of Collaborative and Acknowledged SoSE
Capability Affects Half of the Systems
System Volatility = 2000 Reqs and SoS Capability = 100 Reqs
0.00
1500.00
0
20
40
60
80
100
120
140
160
180
200
1000.00
Savings (Person Months)
Savings (Person Months)
-2000.00
500.00
0.00
0
20
40
60
80
100
120
140
160
180
-4000.00
-6000.00
-8000.00
-10000.00
200
-12000.00
-500.00
-14000.00
Number of Systems
When the Number of Systems is over 12,
Capability affects half of the systems, and the
System and SoS number of requirements are
both equal, SoSE begins to save effort...
October 2008
Number of Systems
For any number of systems, when the Capability
affects half of the systems, and the System
requirements are considerably more that the
SoS requirements, SoSE does not save effort...
(However, there may be other reasons to
employ an SoSE team – future research.)
©USC-CSSE
18
University of Southern California
Center for Systems and Software Engineering
Conclusions
• SoSE team is cost effective when
– SoS contains more than a “few” systems
– SoS capability changes typically affect a “significant
percentage” of constituent systems
– SoS capability requirements are a “significant
percentage” of the total requirements being addressed by
constituent systems in an upgrade cycle
– SoS oversight activities and the rate of capability
modifications/changes being implemented are sufficient
to keep an SoSE team engaged (i.e., little to no slack time)
October 2008
©USC-CSSE
19
University of Southern California
Center for Systems and Software Engineering
Future Work
• Expand System Interdependency SDM to
– Include schedule factors to allow trade-offs between
“faster” and “cheaper”
– Include quality factors based on interdependencies and
the resulting rework
– Allow users to specify specific constituent system
configurations to allow capability alternative trade-offs
• Investigate the factors in going from an
Acknowledged SoS to a Directed SoS
October 2008
©USC-CSSE
20
University of Southern California
Center for Systems and Software Engineering
Questions
October 2008
©USC-CSSE
21
University of Southern California
Center for Systems and Software Engineering
References
ANSI/EIA (1999). ANSI/EIA-632-1988 Processes for Engineering a System.
Dahmann, J. and Baldwin. K. (2008); “Understanding the Current State of US
Defense Systems of Systems and the Implications for Systems
Engineering”, Montreal, Canada: IEEE Systems Conference, 7-10 April.
Department of Defense (DoD) (2008); Systems Engineering Guide for System of
Systems, draft version 1.0.
Maier, M. (1998); “Architecting Principles for Systems-of-Systems”; Systems
Engineering, Vol. 1, No. 4 (pp 267-284)
Valerdi, R. (2005); Constructive Systems Engineering Cost Model. PhD.
Dissertation, University of Southern California.
Valerdi, R. and Wheaton, M. (2005); "ANSI/EIA 632 as a Standardized WBS for
COSYSMO", AIAA-2005-7373, Proceedings of the AIAA 5th Aviation,
Technology, Integration, and Operations Conference, Arlington, Virginia.
Wang, G., Valerdi, R., Ankrum, A., Millar, C., and Roedler, G. (2008), "COSYSMO
Reuse Extension", Proceedings of the 18th Annual International
Symposium of INCOSE, The Netherlands.
October 2008
©USC-CSSE
22