Upload
stephanie-clarke
View
217
Download
0
Tags:
Embed Size (px)
Citation preview
Architecture-Based Drivers for System-of-Systems and Family-of-
Systems Cost Estimating
Gan Wang, Phil Wardle, Aaron Ankrum
BAE Systems
June 25, 2007
Presented to the INCOSE 2007 Symposium page 2
Wisdom of Dilbert
Presented to the INCOSE 2007 Symposium page 3
Agenda
Problem
Two Perspectives of Capability
Architecture-Based Cost Drivers
Conclusions and Further Work
Presented to the INCOSE 2007 Symposium page 4
It’s Your and My Tax Dollars!
Program AgencyAcquisition
CostUnit Cost
Acquisition Cycle Time
Joint Strike Fighter (JSF)*
Joint $224B $91M 16 years
Future Combat Systems (FCS)*
Army$164B - $234B
$8.8B 12 years
Future Aircraft Carrier CVN-21*
Navy $30B $10B 12 ½ years
Global Hawk Unmanned Aircraft*
Air Force $9B $168M 6 ½ years
Tornado Airframe Availability
MoD £1.5B 10 years
*Source: GAO reports
Presented to the INCOSE 2007 Symposium page 5
IssueRFP
Submit Proposal
Award of Contract
Design Reviews
EnterService
End ofService
PDR CDR FCA/PCA
70% ofTotal Ownership Cost Committed 85% of
Total Ownership Cost Committed 90% of
Total Ownership Cost Committed
CONCEPT ASSESSMENT MANUFACTURE IN SERVICE DISPOSALDEMONSTRATION
SDR
SDR = System Design ReviewPDR = Preliminary Design ReviewCDR = Critical Design ReviewPCA = Physical Configuration AuditFCA = Functional Configuration Audit
IOC/FOC
FOC = Full Operational CapabilityIOC = Initial Operational Capability Affordability Under
Regular Review
Affordability in Decision Making
Is this capability affordable if we adopt
the proposed solution?
Presented to the INCOSE 2007 Symposium page 6
Life Cycle Decision Trade Framework
LCC EstimatesEconomicAnalysisROI, NPVPortfolio Mngt.…
Program RisksTechnical MaturityVulnerability…
Program Schedule OperationalRoadmaps…
PerformanceFunctionalityInteroperabilityKPPs, MOEs …
FeasibilityStudy
…
Go/No-goMake/Buy
…
Go/No-goMake/BuyContract
…
DeploymentIOC, FOC
…
Lifecycle Support
…
Tech Insertion
…
Presented to the INCOSE 2007 Symposium page 7
Problem Statement
Develop architecture-based estimating methods/models to provide rough order of magnitude (ROM) estimates for Life Cycle Cost (LCC) of system-of-systems (SoS) and family-of-systems (FoS)
US DoD: “Total Ownership Cost” (TOC)
UK MoD: “Through Life Cost” (TLC)
Provide basis for decision making in capability-based acquisition
Cost of Capability, rather than just the System
Applied in concept/pre-concept phases
This presentation addresses only part of this problem
Presented to the INCOSE 2007 Symposium page 8
Agenda
Problem
Two Perspectives of Capability
Architecture-Based Cost Drivers
Conclusions and Further Work
Presented to the INCOSE 2007 Symposium page 9
AircraftCarrier
AircraftSquadron
DocksideFacility
Operational View of capabilities, roles, missions
e.g. supports the ‘top-table’ discussion between system integrator and the customer
Understanding Capability
CJCSI 3170.01E Definition: “The ability to achieve a desired effect under specified standards and conditions through combinations of means and ways to perform a set of tasks.
Two perspectives on Capability: “Operational” and “Material”
Material View of systems and people
e.g. supports discussions between system integrator and major subcontractors
Source: US Army
Presented to the INCOSE 2007 Symposium page 10
Activity 1
Activity 6 Activity 5
Activity 8Activity 3
Activity 7
Activity 4
Activity 2
Capability Thread B.1
Capability Thread B.2
Capability Thread B.3
Capability Thread B.4
Operational Perspective
Mission Thread A.1
Mission Thread A.1
Mission Thread A.1
Mission Thread A.1
Presented to the INCOSE 2007 Symposium page 11
Material PerspectiveSoS / FoS Work Breakdown Structure
Le
vel 1
Le
vel 2
Le
vel 3
ConceptPhase WBS
Technology Phase WBS
SDD Phase WBS
P&D Phase WBS
O&S Phase WBS
Phase/Spiral Plan
Capability Model
Lifecycle Support
Operational Requirements
Member Systems
Peer Systems
Comms Infrastructure
ValidatedSoS
Integrated & Verified SoS
Deployed SoS
Customer Acceptance
Processes and Resources
Existing Infrastructure
AddedInfrastructure
Current Systems 1..n
Trading System
Architecture Alternatives
Processes, Facilities and Resources for
Project Delivery
Performance, Cost, and Time Requirements
– “shalls”, “shoulds”
Current Systems 1 .. n
Retired Systems n+1 .. n+k
PeerSystems 1 .. n
Test and Integration
Processes and Resources
Operational Facilities and
Resources
Presented to the INCOSE 2007 Symposium page 12
Connecting The ViewsArchitecture Based Cost Estimation
Operational Perspective Material Perspective
DOTMLPF Representation(similarly UK MoD “lines ofdevelopment” - TEPIDOIL)
Captured in DoDAF(similarly MoDAF)
CERs
Mapping
SoS / FoS Work Breakdown Structure
Lev
el 1
Lev
el 2
Lev
el 3
ConceptPhase WBS
Technology Phase WBS
SDD Phase WBS
P&D Phase WBS
O&S Phase WBS
Phase/Spiral Plan
Capability Model
Lifecycle Support
Operational Requirements
Member Systems
Peer Systems
Comms Infrastructure
ValidatedSoS
Integrated & Verified SoS
Deployed SoS
Customer Acceptance
Processes and Resources
Existing Infrastructure
AddedInfrastructure
Current Systems 1..n
Trading System
Architecture Alternatives
Processes, Facilities and Resources for
Project Delivery
Performance, Cost, and Time Requirements
– “shalls”, “shoulds”
Current Systems 1 .. n
Retired Systems n+1 .. n+k
PeerSystems 1 .. n
Test and Integration
Processes and Resources
Operational Facilities and
Resources
Presented to the INCOSE 2007 Symposium page 13
Agenda
Problem
Two Perspectives of Capability
Architecture-Based Cost Drivers
Conclusions and Further Work
Presented to the INCOSE 2007 Symposium page 14
Architecture Based Cost Drivers
1. Number of Operational Nodes
2. Number of Mission-level Operational Scenarios
3. Number of Operational Activities
4. Number of Nodal Information Exchange Boundaries
5. Number of Key (Enabling) Technologies
6. Number of Member Systems
7. Number of Peer Systems
8. Operational Resource/Staffing Level
Capturing the Size of SoS/FoS From Life Cycle PerspectiveCapturing the Size of SoS/FoS From Life Cycle Perspective
Presented to the INCOSE 2007 Symposium page 15
AV
-1
AV
-2
OV
-1
OV
-2
OV
-3
OV
-4
OV
-5
OV
-6a
OV
-6b
OV
-6c
OV
-7
SV
-1
SV
-2
SV
-3
SV
-4
SV
-5
SV
-6
SV
-7
SV
-8
SV
-9
SV
-10a
SV
-10b
SV
-10c
SV
-11
TV
-1
TV
-2
AV OV SV TV
Source and Traceability
DoDAF Views
ConceptRefinement
TechnologyDevelopment
System Development& Demonstration
Production &Deployment
Operations &Support
Pre-Systems Acquisition Systems Acquisition Sustainment
Life CycleImpact
OV
-2
SV
-1
System Development& Demonstration
Production &Deployment
Operations &Support
Operational Nodes
An Operational Node is an organizational structure that may represent an operational role, an organization, or an organizational type, whichever is appropriate for the context; typically, it consists of human operators and systems that they operate on
Operational Nodes can be defined by geographic locations (e.g., fixed or mobile sites), or functional and logical groupings (e.g., logistic function, intelligence function)
Count the “Operational Nodes” at the SoS / FoS level using the OV-2 view
Presented to the INCOSE 2007 Symposium page 16
Use Case Example (1)
Tier 1 Ashore &Support Sites
Tier 1 Afloat
Tier 2 Ashore & Support Sites
Tier 2 Afloat
Concentrator
BUC
Physical
External
Logical
T1:AshDCGS-N
T1:AflDCGS-N
T2:AshDCGS-N
T2:AflDCGS-N
DCGS-NEnterprise
ConcDCGS-N
OV-02 D1.1_L0_NormalOperations (OV-02 Op. NodeConnectiv ity), READ ONLY
System ArchitectFri Jul 22, 2005 07:57
Comment
UNCLASSIFIED**DRAFT**
LEGEND
T1:Ash W eaponsand Mission
Planning
T1:Afl W eaponsand Mission
Planning
T2:Ash W eaponsand Mission
Planning
T2:Afl W eaponsand Mission
Planning
SCI ExternalCustomer
TheaterData
Source
SecretExternal
Customer
T1:AshCommand and
Control
T1:AflCommand and
Control
T2:AshCommand and
Control
T2:AflCommand and
Control
BUCDCGS-N
T1:Ash UHFReceiver
T1:Afl UHFReceiver
T2:Ash UHFReceiver
T2:Afl UHFReceiver
SIGINTData
Source
OrganicData
Source
GEOINTData
Source
NTMData
Source
CollectionPlanning
Conc DCGS-N-DCGS-N Enterprise
SIGINT Data Source-T1:Ash DCGS-N
SIGINT Data Source-T1:Afl DCGS-N
SIGINT Data Source-T2:Ash DCGS-N
SIGINT Data Source-T2:Afl DCGS-N
T1:Ash DCGS-N-DCGS-N Enterprise
DCGS-N Enterprise-T1:Ash DCGS-N
T2:Afl DCGS-N-DCGS-N Enterprise
DCGS-N Enterprise-T2:Afl DCGS-N
T2:Ash DCGS-N-DCGS-N Enterprise
DCGS-N Enterprise-T2:Ash DCGS-N
T1:Afl DCGS-N-DCGS-N EnterpriseDCGS-N Enterprise-T1:Afl DCGS-N
T1:Ash UHF-T1:Ash DCGS-N T1:Ash DCGS-N-
T1:Ash C2
T1:Ash C2-T1:Ash
DCGS-N
T1:AshDCGS-N-
T1:AshW eapons
T1:AshW eapons-
T1:AshDCGS-N
T1:AflW eapons-
T1:AflDCGS-N
T1:Afl DCGS-N-T1:Afl
W eaponsT1:Afl C2-
T1:AflDCGS-N
T1:Afl DCGS-N-T1:Afl C2
T1:Afl UHF-T1:Afl DCGS-N
T2:Ash UHF-T2:Ash DCGS-N T2:Ash DCGS-N-
T2:Ash C2
T2:Ash C2-T2:Ash
DCGS-N
T2:AshDCGS-N-
T2:AshW eapons
T2:AshW eapons-
T2:AshDCGS-N
T2:AflW eapons-
T2:AflDCGS-N
T2:AflDCGS-N-
T2:AflW eapons
T2:Afl C2-T2:Afl
DCGS-N
T2:AflDCGS-N-T2:Afl C2
T2:Afl UHF-T2:Afl DCGS-N
Manual Transfer
Organic Data Source-T1:Afl DCGS-N Manual
Organic Data Source-T1:Ash DCGS-N Manual
Organic Data Source-T2:Afl DCGS-N Manual
Organic Data Source-T2:Ash DCGS-N Manual
GEOINT-T1:Ash DCGS-N
GEOINT-T2:Afl DCGS-N
GEOINT-T2:Ash DCGS-N
GEOINT-T1:Afl DCGS-N
SCI External Customer-T1:Ash DCGS-N
SCI External Customer-T1:Afl DCGS-N
SCI External Customer-T2:Ash DCGS-N
SCI External Customer-T2:Afl DCGS-N
S External Customer-T1:Ash DCGS-N
S External Customer-T2:Afl DCGS-N
S External Customer-T2:Ash DCGS-N
S External Customer-T1:Afl DCGS-N
SIGINT Data Source-T1:Ash UHF
SIGINT Data Source-T1:Afl UHF
SIGINT Data Source-T2:Ash UHF
SIGINT Data Source-T2:Afl UHF
T2:Afl DCGS-N-S External Customer
T2:Ash DCGS-N-S External Customer
T1:Afl DCGS-N-S External Customer
Organic Data Source-T2:Afl DCGS-N
Organic Data Source-T1:Afl DCGS-N
Organic Data Source-T2:Ash DCGS-N
NTM Data Source-Conc DCGS-N
Conc DCGS-N-NTM Data Source
Conc DCGS-N-BUC DCGS-N
Conc DCGS-N-T1:Afl DCGS-NT1:Afl DCGS-N-Conc DCGS-N
Conc DCGS-N-T2:Afl DCGS-N
T2:Afl DCGS-N-Conc DCGS-N
T1:Ash DCGS-N-Conc DCGS-N
Conc DCGS-N-T1:Ash DCGS-N
T2:Ash DCGS-N-Conc DCGS-N
Conc DCGS-N-T2:Ash DCGS-N
Theater Data Source-T1:Afl DCGS-N
Buc DCGS-N-Conc DCGS-N
Collection Planning-T2:Afl DCGS-N
Collection Planning-T2:Ash DCGS-N
Collection Planning-T1:Afl DCGS-N
T2:Ash DCGS-N-SCI External Customer
T1:Afl DCGS-N-SCI External Customer
T2:Afl DCGS-N-SCI External Customer
T1:Ash DCGS-N-SCI External Customers
Collection Planning-T1:Ash DCGS-N
Theater Data Source-T1:Ash DCGS-N
Organic Data Source-T1:Ash DCGS-N
T1:Ash DCGS-N-S External Customer
Theater Data Source-Conc DCGS-N
1
2 3
4
5
6
7
There are three types of nodes: Logical, Physical, and External
We use Logical Nodes for our driver quantity – total is seven
There are also have six physical nodes and eight external nodes
Source: US Navy
OV-2
Presented to the INCOSE 2007 Symposium page 17
AV
-1
AV
-2
OV
-1
OV
-2
OV
-3
OV
-4
OV
-5
OV
-6a
OV
-6b
OV
-6c
OV
-7
SV
-1
SV
-2
SV
-3
SV
-4
SV
-5
SV
-6
SV
-7
SV
-8
SV
-9
SV
-10a
SV
-10b
SV
-10c
SV
-11
TV
-1
TV
-2
AV OV SV TV
Source and Traceability
DoDAF Views
ConceptRefinement
TechnologyDevelopment
System Development& Demonstration
Production &Deployment
Operations &Support
Pre-Systems Acquisition Systems Acquisition Sustainment
Life CycleImpact
Information Exchange Boundary
OV
-2
OV
-3
SV
-2
SV
-3
System Development& Demonstration
Production &Deployment
The boundary between two operational nodes in the SoS/FoS for information exchange purposes; a boundary describes the information exchange needs from a producing node to a consuming node; it isn’t necessarily a physical data channel
The base measure is a count of pairs of producing and consuming nodes; if the information flow is bi-directional then the boundary count is two
Derived measures may include the number of data elements, data types, and the number protocols required to support the information exchange
Presented to the INCOSE 2007 Symposium page 18
Use Case Example (2)
External Boundaries
There are two types of boundary: Internal and External
Total of 19 Internal Total of 65 External Overall total = 84
Source: US Navy
Presented to the INCOSE 2007 Symposium page 19
Agenda
Problem
Two Perspectives of Capability
Architecture-Based Cost Drivers
Conclusions and Further Work
Presented to the INCOSE 2007 Symposium page 20
Conclusions
Architecture based cost drivers based on DoDAF views have been identified to be the “big movers” for LCC; the proposition is that these can be used for parametric estimating of ROM costs of future SoS / FoS projects
One step in developing a Architecture Based Cost Estimating model/method
The concept has been presented to stakeholder groups within BAE SYSTEMS, the academic community, and customer community in the US and UK
Stakeholders have acknowledged
a definite need for ROM estimating methodology at pre-concept/concept phase of life cycle
the potential for an architecture-based approach to SoS / FoS estimating for the earliest stages of the lifecycle and as a basis for senior-level decision making, e.g., go/no-go, AoA trades
the potential for improving our strategic decision making capability
Presented to the INCOSE 2007 Symposium page 21
Further Work
Strawman model(s) and CERs for architecture based estimating method, based on combination of heuristic-based analysis and data validation
Bridge between architecting and estimating communities; guidelines and process to better capture architecture for estimating purposes
Interactive trade space where cost and performance are linked to enable AoA tradeoffs and communications of decisions to stakeholders
Presented to the INCOSE 2007 Symposium page 22
Questions & Comments
Gan WangGan Wang
Phil Wardle Phil Wardle
Aaron Ankrum Aaron Ankrum
Presented to the INCOSE 2007 Symposium page 23
Presented to the INCOSE 2007 Symposium page 24
Operational Scenarios
AV
-1
AV
-2
OV
-1
OV
-2
OV
-3
OV
-4
OV
-5
OV
-6a
OV
-6b
OV
-6c
OV
-7
SV
-1
SV
-2
SV
-3
SV
-4
SV
-5
SV
-6
SV
-7
SV
-8
SV
-9
SV
-10a
SV
-10b
SV
-10c
SV
-11
TV
-1
TV
-2
AV OV SV TV
Source and Traceability
DoDAF Views
ConceptRefinement
TechnologyDevelopment
System Development& Demonstration
Production &Deployment
Operations &Support
Pre-Systems Acquisition Systems Acquisition Sustainment
Life CycleImpact
An “operational Scenario” is a sequence of interconnected activities or course of action at mission level that is triggered by an external situation or event, such as a threat alert or emerging need, resulting in the achievement of a mission objective or outcome
Count the “Operational Scenarios” in terms of end-to-end threads at mission level
It is possible that a given objective or outcome may be achieved by multiple operational scenarios
Presented to the INCOSE 2007 Symposium page 25
Operational Activities
AV
-1
AV
-2
OV
-1
OV
-2
OV
-3
OV
-4
OV
-5
OV
-6a
OV
-6b
OV
-6c
OV
-7
SV
-1
SV
-2
SV
-3
SV
-4
SV
-5
SV
-6
SV
-7
SV
-8
SV
-9
SV
-10a
SV
-10b
SV
-10c
SV
-11
TV
-1
TV
-2
AV OV SV TV
Source and Traceability
DoDAF Views
ConceptRefinement
TechnologyDevelopment
System Development& Demonstration
Production &Deployment
Operations &Support
Pre-Systems Acquisition Systems Acquisition Sustainment
Life CycleImpact
Operational Activities are major tasks performed in support of a mission objective or outcome; they can be subdivided - a single activity can be decomposed to a series of activities at the next level breakdown
Count the “Operational Activities” for each mission-level operational scenario
We define Operational Activities at the mission level and they are building blocks of the Operational Scenarios
Presented to the INCOSE 2007 Symposium page 26
Key Technologies
AV
-1
AV
-2
OV
-1
OV
-2
OV
-3
OV
-4
OV
-5
OV
-6a
OV
-6b
OV
-6c
OV
-7
SV
-1
SV
-2
SV
-3
SV
-4
SV
-5
SV
-6
SV
-7
SV
-8
SV
-9
SV
-10a
SV
-10b
SV
-10c
SV
-11
TV
-1
TV
-2
AV OV SV TV
Source and Traceability
DoDAF Views
ConceptRefinement
TechnologyDevelopment
System Development& Demonstration
Production &Deployment
Operations &Support
Pre-Systems Acquisition Systems Acquisition Sustainment
Life CycleImpact
Technologies that enable and underpin the mission capabilities under consideration
An example of a “technology” might be the Service-Oriented Architecture for an integrated Intelligence, Surveillance, and Reconnaissance (ISR) capability
A technology could be either under development for the SoS / FoS being estimated, or could be an established technology but with rework issues such as refresh or mitigation of obsolescence
Presented to the INCOSE 2007 Symposium page 27
Member Systems
AV
-1
AV
-2
OV
-1
OV
-2
OV
-3
OV
-4
OV
-5
OV
-6a
OV
-6b
OV
-6c
OV
-7
SV
-1
SV
-2
SV
-3
SV
-4
SV
-5
SV
-6
SV
-7
SV
-8
SV
-9
SV
-10a
SV
-10b
SV
-10c
SV
-11
TV
-1
TV
-2
AV OV SV TV
Source and Traceability
DoDAF Views
ConceptRefinement
TechnologyDevelopment
System Development& Demonstration
Production &Deployment
Operations &Support
Pre-Systems Acquisition Systems Acquisition Sustainment
Life CycleImpact
“Member Systems” comprise component parts of the SoS / FoS
Count the “Operational Systems” and “Life Cycle Support Systems” at each Operational Node; these may be created from scratch (to achieve new capabilities) or enhanced (to improve legacy capabilities)
Operational Systems directly contribute to the achievement of a SoS / FoS mission objective or outcome
Life Cycle Support Systems typically contribute to ongoing system development, integration, calibration, and maintenance
Presented to the INCOSE 2007 Symposium page 28
Peer Systems
AV
-1
AV
-2
OV
-1
OV
-2
OV
-3
OV
-4
OV
-5
OV
-6a
OV
-6b
OV
-6c
OV
-7
SV
-1
SV
-2
SV
-3
SV
-4
SV
-5
SV
-6
SV
-7
SV
-8
SV
-9
SV
-10a
SV
-10b
SV
-10c
SV
-11
TV
-1
TV
-2
AV OV SV TV
Source and Traceability
DoDAF Views
ConceptRefinement
TechnologyDevelopment
System Development& Demonstration
Production &Deployment
Operations &Support
Pre-Systems Acquisition Systems Acquisition Sustainment
Life CycleImpact
“Peer Systems” are part of some other SoS / FoS and under some other line of command and control, yet they interact with the SoS / FoS of interest
Count the “Peer Systems” so as to take account of their effect on the cost of integration for the SoS /FoS of interest
Member Systems from the SoS / FoS of interest may have to interface with Peer Systems in order to enable and underpin the achievement of a mission objective or outcome; achievement of the interface relies on negotiation and collaboration to establish the interface protocols
Presented to the INCOSE 2007 Symposium page 29
Operational Resources
AV
-1
AV
-2
OV
-1
OV
-2
OV
-3
OV
-4
OV
-5
OV
-6a
OV
-6b
OV
-6c
OV
-7
SV
-1
SV
-2
SV
-3
SV
-4
SV
-5
SV
-6
SV
-7
SV
-8
SV
-9
SV
-10a
SV
-10b
SV
-10c
SV
-11
TV
-1
TV
-2
AV OV SV TV
Source and Traceability
DoDAF Views
ConceptRefinement
TechnologyDevelopment
System Development& Demonstration
Production &Deployment
Operations & Support
Pre-Systems Acquisition Systems Acquisition Sustainment
Life CycleImpact
Staffing level of the operators represents the operational resources involved in the day-to-day delivery of mission objectives or outcomes
The staffing level is typically represented in an organizational structure with an arrangement of responsibilities, authorities and relationships; it can also be represented by functions and roles
The staffing levels can be counted as number of people or as number of operational units of a uniform size, e.g., battalion as in military unit