![Recommended TB Components for an "SAD" Baseline throughout DAS Process with Support from JCIDS and DODAF 3. Impacts of Integrated Program Management Approach on TB Recently, most DOD programs have employed modern Integrated Program Management (IPM 9 ) approach to reduce risk and cost of acquiring and executing programs. As shown in Figure 7, the IPM is used to integrate and synchronize Program Requirements (PRes) (including both technical and programmatic) and SAD with (i) Program Cost (PC), (ii) Program Schedule (PS), and (iii) Program Risks (PRis) (including both technical and programmatic) [Ref. 6]. Unlike the TB, which only includes the technical elements of a program, i.e., TechnicalRequirements (TRes) and SAD, a PTB must include PTB components that cover five-key program baselines: (i) Stakeholder PRes Technical-and-Programmatic-Requirements baseline, (ii) SAD baseline, (iii) PC baseline, (iv) PS baseline (including resource allocation baseline), and (v) Technical-and-Programmatic risk baseline. In order to achieve an initial balanced design baseline, the five-key baselines are linked together using specific Program Management (PM)/System Engineering (SE)/Cost/Risk processes and tools. The PTB components are tracked over the program life cycle and changes are captured and updated at each milestones throughout the DAS process.](https://www.researchgate.net/profile/Tien-Nguyen-115/publication/300792485/figure/fig1/AS:614105119457281@1523425478114/Recommended-TB-Components-for-an-SAD-Baseline-throughout-DAS-Process-with-Support-from_Q320.jpg)
Content uploaded by Tien M. Nguyen
Author content
All content in this area was uploaded by Tien M. Nguyen on Feb 21, 2018
Content may be subject to copyright.
A Resilient Program Technical Baseline Framework
for Future Space Systems
(2015 SPIE Invited Paper)
Tien M. Nguyen
1
, Andy T. Guillen, Sumner S. Matsunaga
The Aerospace Corporation
2310 E. El Segundo Blvd. El Segundo, CA 90245-4609
Abstract
Recent Better Buying Power (BBP) initiative for improving DoD’s effectiveness in developing complex systems includes
“Owning the Technical Baseline” (OTB). This paper presents an innovative approach for the development of a “Resilient
Program” Technical Baseline Framework (PTBF). The framework provides a recipe for generating the “Resilient
Program
2
” Technical Baseline (PTB) components using the Integrated Program Management (IPM) approach to integrate
Key Program Elements (KPEs)
3
with System Engineering (SE) process/tools, acquisition policy/process/tools, Cost and
Schedule estimating tools, DOD Architecture Framework (DODAF) process/tools, Open System Architecture (OSA)
process/tools, Risk Management process/tools, Critical Chain Program Management (CCPM) process, and Earned Value
Management System (EVMS) process/tools. The proposed resilient framework includes a matrix that maps the required
tools/processes to technical features of a comprehensive reference U.S. DOD “owned” technical baseline. Resilient PTBF
employs a new Open System Approach (OSAP) combining existing OSA
4
and NOA (Naval Open Architecture)
frameworks, supplemented by additional proposed OA (Open Architecture) principles. The new OSAP being
recommended to SMC (Space and Missiles Systems Center) presented in this paper is referred to as SMC-OSAP
5
.
Resilient PTBF and SMC-OSAP conform to U.S. DOD Acquisition System (DAS), Joint Capabilities Integration and
Development System (JCIDS), and DODAF processes. The paper also extends Ref. 21 on “Program Resiliency” concept
by describing how the new OSAP can be used to align SMC acquisition management with DOD BBP 3.0 and SMC’s vison
for resilient acquisition and sustainment efforts.
Keywords: Program Technical Baseline Framework, Affordable, Resilient, Integrated Program Management, Open
System Architecture, Critical Chain Program Management, Acquisition, Sustainment, Space and Missile Systems Center.
1. Introduction
The U.S. Department of Defense (DOD) is focused on modernizing [Ref. 1] existing space systems and development of
future space systems using BBP 3.0 [Refs. 2, 3] and Congressional [Ref. 4] initiatives to improve acquisition and
sustainment efficiency. These initiatives impose three key requirements on the development of future space systems,
including making affordability a requirement for the life of a program, increasing competition, and decreasing the time it
takes to acquire a system. Also, the Space Modernization Initiative (SMI) Strategy [Ref. 1] promotes modernization of
existing space systems that meet three strategic objectives; namely, design for low Life Cycle Cost (LCC) for affordability,
provide desired system capability to meet warfighter needs, and achieve resiliency to operate in contested environments.
SMC’s vision for achieving both strategic objectives and acquisition initiatives is through “Affordable” and “Resilient”
acquisition and sustainment strategies. This requires a solid PTB to enable the government and industry partners to
effectively manage these developments; improving the basis for competition, assisting government source selection
authorities to effectively select among proposed technical solutions, and enabling government-industry partners to
effectively manage the system life cycle through development, operations, and sustainment. This invited paper proposes
an innovative Resilient PTBF that provides a recipe to generate resilient PTB components for future space systems.
1
E-mails: tien.m.nguyen@aero.org; andy.t.guillen@aero.org; sumner.s.matsunaga@aero.org
2
“Resilient Program” or “Program Resiliency” is defined as the program that achieves both SMC’s vision and “Four” BBP 3.0 Initiatives with its PTB
components generated by the PTB framework described in this paper. Note that the “Four” initiatives are described in Section 1 of this paper.
3
Five KPEs include Program/Technical Requirements (Pres), System Architecture Design (SAD), Program Risks (PRis), Program Cost (PC), and
Program Schedule (PS).
4
OSA is also referred to as Modular Open System Approach or MOSA that was initiated at the Department of Defense in November 1994.
5
Note that the newly SMC-OASP is being recommended to SMC, and SMC has not adopted the proposed OSAP yet.
© 2015 The Aerospace Corporation
Sensors and Systems for Space Applications VIII, edited by Khanh D. Pham,
Genshe Chen, Proc. of SPIE Vol. 9469, 946907 · © 2015 SPIE
CCC code: 0277-786X/15/$18 · doi: 10.1117/12.2180368
Proc. of SPIE Vol. 9469 946907-1
Downloaded From: http://proceedings.spiedigitallibrary.org/ on 05/26/2015 Terms of Use: http://spiedl.org/terms
The paper considers two types of SMC acquisition and sustainment efforts, including: (i) New Space Systems Development
(NSSD), and (ii) Modernization of existing space systems or SMI efforts [Ref. 1]. The affordability metric for NSSD
efforts is Total Ownership Cost (TOC)
6
, and for SMI efforts is LCC
7
. The paper describes the existing TB (Technical
Baseline) for both NSSD and SMI efforts based on DAS, JCIDS, and DODAF processes, and addresses impacts of IPM
on the existing TB. The paper defines Program TB (PTB) and
describes the differences between TB and PTB for both NSSD and
SMI efforts.
In September of 2014, the DOD introduced the BBP 3.0 strategy
encourages innovation and promotes technical excellence with the
overarching goal of ensuring that the U.S. military has the dominant
capabilities to meet future national security requirements [Refs. 2].
BBP 3.0 comprises eight initiatives shown in Figure 1. USAF began
developing plans for implementing the “Eight” BBP 3.0 initiatives
[Ref. 3]; this paper focuses on the “Four” BBP 3.0 Initiatives (i), (ii),
(iv) and (vi). The paper describes a new OSAP that achieves the “Four Initiatives” by combining existing OSA and NOA
frameworks, and integrating the combined framework with the newly proposed OA principles. The integrated OSAP is
being recommended to SMC and is referred to as “SMC-OA”.
The focus of the paper is on the “Resilient” PTBF that achieves “Program Resiliency” defined in Ref. 21 by aligning
SMC’s vision with the Four-BBP 3.0 Initiatives. Emphasis of the Four BBP 3.0 initiatives is on affordable program,
technology insertion and refresh in program planning, and use of MOSA to stimulate innovation and promote effective
competition. The paper presents an approach to incorporate the newly recommended SMC-OSAP into the PTBF that can
be used as a recipe to generate resilient PTB components (hence Resilient PTBF), and matrices that capture the required
tools/processes with respect to technical features of a comprehensive reference U.S. DOD “owned” PTB components.
This paper is organized as follows: Section 2 provides a description of the existing TB and discusses how the DAS,
DODAF and JCIDS processes influenced the existing TB components [Ref. 5]; Section 3 describes a recent IPM approach
and how it affects the TB, and presents the concept of PTB and discusses the differences between TB and PTB
components; Section 4 describes existing OSA and NOA frameworks, and discusses “Program Resiliency” and its
relationship with existing frameworks, the Four-BBP 3.0 Initiatives (i)-(ii)-(iv)-(vi) and SMC’s current vision on
“Affordable” and “Resilient” acquisition and sustainment of NSSD and SMI efforts; Section 5 describes the
implementation approach for “Program Resiliency” and recommends to SMC an integrated OSAP, which is also referred
to as SMC-OSAP, that can achieve the Four-BBP 3.0 Initiatives and aligns with SMC’s vision on “Affordable” and
“Resilient” acquisition and sustainment; Section 6 presents an IPM approach using combined SMC-
OSAP/DAS/JCIDS/DODAF and discusses its impacts on PTB; Section 7 presents the resilient PTBF and provides matrices
that captures the required tools/processes with respect to technical features of a comprehensive reference U.S. DOD
“owned” and contractor “owned” resilient PTB components; and Section 8 concludes the paper by providing a conclusion,
recommendation and a way-forward.
2. Existing Technical Baseline Components
2.1 Common View of a Technical Baseline (TB)
The common view on the existing TB is described in Ref. 6, where it provides a description of the TB based for the NASA
Life Cycle Phases (LCP). The key components of NASA TB are dependent on the NASA LCP, and their definitions are
summarized in Table 1. On the other hand, the Air Force Center for Systems Engineering, Wright Patterson Air Force
Base (WPAFB), OH [Ref. 7], has defined a TB as all the technical information required to support a product/program
throughout its life cycle, and that there are many different approval processes involved with TB configuration change
control, TB Maintenance procedures, TB Verification and Validation, and System certification. Figure 2 describes
WPAFB’s high-level view of the TB and associated information needed to be archived and maintained throughout a
6
TOC is more than LCC. It deals with both indirect and direct cost to achieve affordability requirement.
7
LCC for SMI efforts is not just the acquisition cost, it deals with all direct cost associated with the modernization effort for the entire life of a
program, assuming that the indirect cost is already incurred with the existing systems and there is nothing you can do about it!
Figure 1. Eight BBP 3.0 Initiatives [Ref. 2]
Better Buying Power 3.0 DRAFT
Achieving Dominant Capabilities through Technical Excellence
and Innovation
i. Achieve Affordable Programs
ii. Achieve Dominant Capabilities While Controlling Lifecycle Costs
iii. Incentivize Productivity in Industry and Government
iv. Incentivize Innovation in Industry and Government
v. Eliminate Unproductive Processes and Bureaucracy
vi. Promote Effective Competition
vii. Improve Tradecraft in Acquisition of Services
viii. Improve the Professionalism of the Total Acquisition Workforce
Focus of this Paper
Proc. of SPIE Vol. 9469 946907-2
Downloaded From: http://proceedings.spiedigitallibrary.org/ on 05/26/2015 Terms of Use: http://spiedl.org/terms
Customer l User
Program Direction
Preferences
Needs
11_
Program
Performance Reports
Deficiency Reports
Trandn
Configuration Certert ification
Specs l Dwgsl Code List - r
Product Specific, J
Data Supply
Vendors
Spare Parts
DMS
Production I
Maintenance
Facilities
Training I Certification
:a......a, entry, m
cqui.
E.ol..e...ry ... or =,.e. =ten to C..ata...,
Entrance Cited. nor before ,a....
Alo
Entoneering and
... ówn. ... FOC
Operations
Relationship to JCIDS
1ROC
ICD
Materiel solution
analysts
premilestone A
Draft
CDD
Me A
Materiel Techndogy Acquisition Post.SOR
development development strategy review
decision strategy approval approval
Coordination,
formal draft ROC ROC
CDD CDD CPD
Tectind gy development phase
Design reviews: SRR SDRJSFR
(l?n Capability development document t i:; FWI operating capability
CPU Capability production document PD Initial capabilities document
CPR Critical design review I;,C Initial operating capability
PDR
Engineering and
manufacturing
developmentCDR
IOC Fdlow-on FOC
Production
decision
Production and Operations
deployment and support
1án1 Requonnents Oversight Council
Preliminary design review
System design review
System functional review
System requirements review
product’s life cycle. Both NASA’s and WPAFB’s views on TB are focused more on the technical aspects of a program.
WPAFB’s TB has included two components related to program requirements, such as program direction and user needs.
In the subsequent Sub-sections 2.2 and 2.3, TB definition and key TB components will be presented based on (i) NASA’s
and WPAFB’s views, and (ii) our assessment of the DAS with support from JCIDS and DODAF processes on TB.
Table 1. NASA Description of TB Components [Ref. 6]
2.2 TB Definition Based on Existing DOD Acquisition System (DAS) and JCIDS Processes
Current DAS defines the decision acquisition process and provides a list of specific technical information required at each
Milestone (MS) during the process (see Figure 3.a) [Refs. 5, 8, 9]. U.S. DOD applies JCIDS processes to define warfighter
requirements input to the DAS process [Refs. 10, 11], and the processes generate specific capability documents and support
information to support DAS acquisition decisions at each MS (see Figure 3.b). The three key capabilities based
requirements documents generated from JCIDS processes are the Initial Capabilities Document (ICD), the Capability
Development Document (CDD), and the Capability Production Document (CPD) [Ref. 10]. ICD
8
generates a capability
based planning document and lays the foundation for additional analysis and discovery. The ICD supports the AoA
(Analysis-of-Alternatives), the Technology Development Strategy, the MS A decision, and subsequent Technology
Development activities. The CDD, guided by the ICD, the AoA, and the TDS, captures the information necessary to
initiate an acquisition program to develop a proposed capability, normally using an evolutionary acquisition strategy. The
CDD outlines an affordable increment of capability using mature technology and supports MS B. The CPD supports MS
C and is developed after the Design Readiness Review (DRR). The CPD must be approved before Low Rate Initial
Production (LRIP) and Initial Operational Test & Evaluation (IOT&E). Thus, the TB components vary with DAS phase
and influenced by JCIDS analysis. Similar to NASA definition of a TB, the TB definition in the context of DAS and JCIDS
is provided in Figure 4.
Figure 3.a. DOD Acquisition System (DAS) [Refs. 8, 9] Figure 3.b. JCIDS Support of DAS [Ref. 11]
2.3 Impacts of DAS, JCIDS and DODAF Processes on TB Components
As mentioned in Sub-sections 2.1 and 2.2, the current views on TB components mainly require the technical information
needed to support a program throughout its life cycle. Thus, the two key program “Technical” elements that require to
baseline at each DAS milestone are the “Technical-Requirements (TRes)” and “System Architecture Design (SAD)” (see
Footnote 3). Based on the DOD Instruction 5000.02 [Ref. 5] and JCIDS manual [Ref. 10] with support from DODAF
8
For an IT-intensive program, it may only have an IS ICD, and may not have a CDD, and pretty much does not have a CPD.
Life Cycle
Phase
TB Description
A
Functional Baseline: The functi ona l b as eli ne is the a pprove d docu menta tion des crib ing a
sys tem’s functi ona l, p erforma nce, a nd i nte rface re qui remen ts a nd th e veri fica tion s req uire d
to d emon strate ach ieve ment o f thos e s peci fie d cha racteri sti cs.
B
Allocated Baseline aka the ‘Design-to’ Baseline: The al loca ted b as eli ne extend s th e top- leve l
pe rforman ce req uire ments of th e fun ction al bas el ine to s uffici ent deta il for in iti atin g
ma nufa cturing or codi ng.
C
Product Baseline aka the ‘Build-to’ Baseline: The product b as eli ne des cribe s d etai le d form, f it,
an d fun ction chara cteris tics ; the s el ected functi ona l cha racte risti cs d es igna ted f or prod uction
acce ptan ce tes tin g; the p roducti on a ccepta nce te st re qui remen ts.
D
‘As-Built’ Baseline: The as -bui lt b ase li ne d es crib es the d etai le d form, f it, a nd fu nction of the
sys tem a s i t wa s bu ilt.
E
Operational Baseline aka ‘As-Deployed’ Baseline : Th e a s-de plo yed b ase li ne o ccurs a t the
Ope ratio nal Rea di nes s Re view (ORR) . At this poi nt, the des ign is cons ide red to be f unctio nal
an d rea dy for fl igh t. All chan ges wil l h ave b een inco rporate d in to the fin al docume ntati on.
Figure 2. WPAFB Description
of TB Components [Ref. 7]
Proc. of SPIE Vol. 9469 946907-3
Downloaded From: http://proceedings.spiedigitallibrary.org/ on 05/26/2015 Terms of Use: http://spiedl.org/terms
Q
Initial
Capabilities
Document.
Materiel
Development
Decision
Materiel
Solution
Matis
Requirmbents
Auawrity
Review of AoA
Resulls
Draft
Capability
Development
Document
A
[l
Letlentl
= Decision Point
= Milestone Decision
= Requirements Document
= Requirements Authority
Review
Technology Maturation &
Risk Reduction Phase
L.
Capability
Development
Document'
Or Equivalent Approved/Validated Requirements Document.
Engineering & Manufacturing
Development Phase
Capability
Production
Document' Production &
Deployment Phase
Operations & Support
Phase DI
process [Ref. 20] and DoD DAG (Decision Acquisition Guidebook) [Ref. 22], we generate a set of TB components
required to capture the baselines of “Technical-Requirements” and SAD at each DAS milestone, and the components are
captured in Figures 5 and 6, respectively. As shown in Figures 5 and 6, the DODAF process is used to capture architecture
artifacts throughout the life of a program. As an example, from Figure 5, at MS A, the required TB components for a TRes
Baseline includes a validated ICD, a draft IS (Information Support) Plan, AoA results, Technology Development Plan,
Draft System Engineering Plan (SEP), Draft CDD and CONOPS, Integrated Program Summary (IPS), Test and Evaluation
Master Plan (TEMP) and System Threat Assessment Report (STAR). Similarly, from Figure 6, at MS A, the required TB
components for an “SAD” Baseline include a validated Functional Architecture Baseline with DODAF Artifacts (See
SMC-S-001 (2013) [Ref. 12], Section 3.2.2), Draft Allocated Baseline with Additional DODAF Artifacts (see SMC-S-001
(2013), Section 3.2.3), and a list of identified Key Critical Technology Elements (CTEs).
Figure 4. Proposed Definition for TB Components in the Context of DAS and JCIDS
Figure 5. Recommended TB Components for a “TRes” Baseline throughout DAS Process with Support from JCIDS and DODAF
Milestone A Technical Baseline (MA-TB): is defined as Functional Baseline (FB), which is a set of DODAF views and documents describing a system’s
functional, performance, and functional requirements and the verifications required to demonstrate achievement of those specified characteristics in ICD/TRD
Milestone B Technical Baseline (MB-TB): is defined as the Allocated Baseline (aka “Design-to” baseline), which is a set
of DODAF views and associated documents extending the top-level performance requirements of the FB to
sufficient detail for initiating technology maturation and risk reduction planning according to the CDD/TRD
Pre-Milestone C Technical Baseline (PMC-TB): is referred to as the “Design Release”, which is a set of DODAF Views
and associated documents describing detailed system form, fit, and function characteristics; the selected
functional characteristics designated for production acceptance testing; the production acceptance test
requirements according to the CPD/TRD
Milestone C Technical Baseline (MC-TB): is referred to as “Product Configuration” baseline,
which is a set of DODAF Views and associated documents describing the
detailed form, fit, and function of the system as it will be built.
Production & Deployment Technical Baseline
(O&D-TB): is referred to as “Transition &
Deployment” baseline, which is a set of
DODAF views and associated documents
describing detailed operational and
deployment support of the system
deployed in the field
Proposed Technical Baseline (TB) Definition in the Context of DAS and JCIDS
Technical Requirements Milestone: A
1.ICD Validated
2.Draft Information Support (IS): ICD for implementing IT box
- If cost drives MDAP, CDD requires for Development –IS with SW
cost < 15M -> not subject to JCIDS)
3.AoA Results: (i) KPPs/ KSAs/Additional Performance Attributes (APAs),
(ii) System Attribute needs Technology Development, (iii) Current TRLs
4.Technology Development Plan (TDP)
5. Draft System Engineering Plan (SEP)
6. Draft CDD/TRD
7. Integrated Program Summary (IPS) from acquisition office
8. Test and Evaluation Master Plan (TEMP)
9. System Threat Assessment Report (STAR)
Milestone: B
1. IS Plan
2. TEMP Updated to Achieve
TRL-6
3. SEP Updated
4. STAR Updated
5. DD Form 1494
6. TRD (required for
breadboard and prototyping
to mature technology)
7. Refine of KPPs/KSAs/APAs
8. “Full” CDD per AFI 63-
101/20-101 Validated
9. Acquisition Program Baseline
(APB) Established
Milestone: Pre-MS C
1. Draft System Integration
Plan
2.Generate System
Requirements from
TRD/CDD
3.Draft CPD
- Production KPPs/KSAs/
APAs
- Spectrum Requirements
(Form DD-1494)
- Manufacturing Readiness
Assessment
- Intelligence Supportability
- Weapon Safety Assurance
Milestone: Production and
Deployment
1.LRIP: Produce Articles for
IOT&E
Milestone: C
1.IS Plan Updated
2.SEP Updated
3.CDR
4.DD Form 1494
5.STAR Updated
6.APB Updated
7.CPD validated
8.System Requirements
Validated
9.System Integration Plan
validated
- JCIDS Manual, 12 February 2015
- DOD Instruction 5000.02, 07 January 2015
Proc. of SPIE Vol. 9469 946907-4
Downloaded From: http://proceedings.spiedigitallibrary.org/ on 05/26/2015 Terms of Use: http://spiedl.org/terms
..... DI --
¡.... -
.... .... ;
t"'"
Figure 6. Recommended TB Components for an “SAD” Baseline throughout DAS Process with Support from JCIDS and DODAF
3. Impacts of Integrated Program Management Approach on TB
Recently, most DOD programs have employed modern Integrated Program Management (IPM
9
) approach to reduce risk
and cost of acquiring and executing programs. As shown in Figure 7, the IPM is used to integrate and synchronize Program
Requirements (PRes) (including both technical and programmatic) and SAD with (i) Program Cost (PC), (ii) Program
Schedule (PS), and (iii) Program Risks (PRis) (including both
technical and programmatic) [Ref. 6]. Unlike the TB, which only
includes the technical elements of a program, i.e., Technical-
Requirements (TRes) and SAD, a PTB must include PTB
components that cover five-key program baselines: (i) Stakeholder
PRes Technical-and-Programmatic-Requirements baseline, (ii)
SAD baseline, (iii) PC baseline, (iv) PS baseline (including
resource allocation baseline), and (v) Technical-and-Programmatic
risk baseline. In order to achieve an initial balanced design baseline,
the five-key baselines are linked together using specific Program
Management (PM)/System Engineering (SE)/Cost/Risk processes
and tools. The PTB components are tracked over the program life
cycle and changes are captured and updated at each milestones
throughout the DAS process.
As illustrated in Figure 7, the proposed PM/SE/Cost/Risk tools and processes include: (i) Standard Program Management
(PM) practice, which employs standard PM processes and tools such as schedule/cost/resource/manufacturing
resource/manufacturing capacity planning and management, change management, supply chain management, etc, (ii)
Earned Value Management System (EVMS), which employs process and tool to integrate PC with PS and technical
requirements, including PRes & SAD, and to assess and track the cost/schedule performance and program Critical Paths
(CPs), (iii) Critical Chain Program Management (CCPM) process and tool, which are employed to integrate SAD tasks
and resources (cost and schedule to perform the tasks) to identify CPs, provide resource buffers and avoid multi-tasking
on CPs, and (iv) SE, which employs existing USAF SE processes and tool to integrate PRes and SAD to meet warfighter
needs and achieve affordability. Note that for system design using OSAP, a specialty SE process needs to be developed
and used for integrating MOSA/NOA principles/frameworks into PRes, SAD and program LCC/TOC to meet warfighter
needs and achieve affordability with increased competition.
9
IPM is not the same as IMP (Integrated Master Plan). IMP is an event-based is an event-based, top level plan consisting of a hierarchy of Program
Events.
System Architecture Design (SAD) Milestone (MS): A
1.Functional Architecture Baseline with DODAF Artifacts
validated (See SMC-S-001 (2013), Section 3.2.2)
- DODAF Artifacts validated include: AV-1, AV-2, CV-2,
CV-6, OV-1, 0V-2, OV-4, OV-5a
2.Draft Allocated Baseline with Additional DODAF Artifacts
(see SMC-S-001 (2013), Section 3.2.3):
-CV-1, CV-2, CV-3, CV-4, CV-5, DIV-2, OV-3, OV-5b,
OV-6c, PV-2, SV-1 or SvcV-1, SV-2 or SvcV-2, SV-4 or
SvcV-4, SV-5a or SvcV-5, SV-6 or SvcV-6, SV-7 or
SvcV-7 (NR-KPP), StdV-1 (or TV-1), StdV-2 (or TV-2)
3. Key Critical Technology Elements (CTEs) Identified
Milestone: B
1. CTEs matured to TRL-6
2. Technology Roadmap
Developed Using Technology
Development Plan
3. Allocated Baseline (see SMC-
S-001 (2013), Section 3.2.3)
Validated with DOAAF Artifacts
Developed in MS A
Milestone: Production and
Deployment
1.“Product Configuration”
Baseline (see SMC-S-001
(2013), Section 3.2.5)
Validated
2.Transition & deployment
Baseline (see SMC-S-001
(2013), Section 4.1.7)
Validated
3.Supportability Baseline (SMC-
S-001, Sect 4.1.8) Validated
4.Disposal Baseline (SMC-S-
001, Sect 4.1.9) Validated
5.MFCA* Baseline (SMC-S-
001, Sect 4.1.10) Validated
*MCFA = Mission Critical Fault
Analysis
Milestone: C
1.“Design Release” Baseline
(see SMC-S-001 (2013),
Section 3.2.4) Validated
2.Draft “Product
Configuration” baseline (see
SMC-S-001 (2013), Section
3.2.5) updated
3. Draft “Transition &
deployment Baseline” (see
SMC-S-001 (2013), Section
4.1.7)
Milestone: Pre-MS C
1.Draft “Design Release”
Baseline (see SMC-S-001
(2013), Section 3.2.4) with
Additional DODAF Artifacts
including:
- DIV-3 (or SV-11)
2.Draft “Product
Configuration” baseline (see
SMC-S-001 (2013), Section
3.2.5)
- JCIDS Manual, 12 February 2015.
- DOD Instruction 5000.02, 07 January 2015.
- DODAF 2.02
- SMC-S-001
Earned Value management System
Standard Program Management
Chain
Critical
Management Program
Program
Cost
(PC)
System
Architecture
Design (SAD)
Program
Schedule
(PS)
Program
Risks
(PRis)
System
Engineering
Program
Requirements
(PRes)
Figure 7. IPM Integrates Five KPEs
Proc. of SPIE Vol. 9469 946907-5
Downloaded From: http://proceedings.spiedigitallibrary.org/ on 05/26/2015 Terms of Use: http://spiedl.org/terms
Vision
MOSA is an
integral part of all
acquisition strategies to
achieve affordable,
evolutionary,
and joint combat
capability
Principles
stablish Enabling Environment
Employ Modular Design
Designate Key Interfaces
Select Open Standards
Certify Conformance
Benefits
Ease of Change
Reduced Total Ownership Cost
Reduced Cycle-Time
V Enabling Joint Integrated
Architectures and Interoperability
V Risk Mitigation
Indicators
4. Program Resiliency: Relationship Among BBP 3.0, OSA and SMC’s Vision
As mentioned earlier, USAF has begun to implement the eight initiatives shown in Figure 1 [Ref. 3]. This section focuses
on “Four” BBP 3.0 Initiatives (i), (ii), (iv) and (vi) with emphasis on affordable program, control LCC, technology
insertion and refresh in program planning, the use of MOSA to stimulate innovation and promote effective competition.
The relationship among these Four initiatives with existing OSA and NOA, and SMC’s vision on “Affordable” and
“Resilient” acquisition and sustainment strategies is discussed below. Note that OSA is formerly known as MOSA (see
Footnote 5).
MOSA is an Open System Approach
(OSAP) that integrates business and
technical strategies that employs five
principles as described in Figure 8,
namely, (i) Establish enabling
environment, (ii) Employ modular design,
(iii) Designate key interfaces, (iv) Select
open standards, and (v) Certify
performance [Refs 13, 14, 15, 16]. As also
illustrated in Figure 8, USN (U.S. Navy)
has implemented MOSA and improved
the approach by incorporating additional 5
NOA principles, including (i) Life cycle
affordability, (ii) Encouraging competition and collaboration, (iii) modular design and design disclosure, (iv) Total system
performance, interoperable joint warfighting applications, secure information exchange, and (v) Reusable application
software. The current OSAP commonly used by DOD/USN is to combine OSA and NOA principles shown in Figure 8. It
is observed that the current OSAP does not provide adequate tools to meet SMC’s vision on “Affordable” and “Resilient”
acquisition and sustainment of future space systems.
To achieve SMC’s vision, this paper defines the “Affordable” acquisition and sustainment strategy as an “Optimum” LCC
or TOC depending on whether the program is NSSD (with new technology) or SMI (with modernized technology) [Ref.
21]. As mentioned previously, optimizing LLC and TOC to achieve minimum (or lowest) cost are for SMI and NSSD
efforts, respectively. Similarly, the “Resilient” acquisition strategy is defined as the “Minimum” Acquisition Cost (MIAC)
to acquire/modernize technology to meet the warfighter needs and achieve “Affordability” by “Increased Competition” or
by “Promotion of Effective Competition”. The proposed approach for implementing the “Resilient” acquisition strategy
that can achieve MIAC is to identify the Critical Technology Elements (CTEs) and their associated Key Sub-Systems
(KSS) and make them “Open,” namely, Key Open Sub-Systems (KOSS). The term “Open” is defined in terms of MOSA
context, i.e., to achieve “Openness” for the selected KOSS, the system architect must use popular, open, non-proprietary
and published interface standards that can allow for “increased competition” and “decreased the time” that it takes to
acquire a space system. Likewise, the “Resilient” sustainment strategy is defined as an approach to “Minimize”
Sustainment Cost (MISC) due to technology changes to meet the “Affordability” requirement for sustaining of a newly
acquired or a modernized space system. The proposed approach for the “Resilient” sustainment strategy that can achieve
MISC is to acquire/modernize a “Technology Agnostic” (TeAg) space system, where the TeAg is defined as the cost of
technology refreshing or insertion for sustaining the acquired/modernized space system is independent of the technology
changes, i.e., the sustainment cost is robust to technology changes. This means that the sustainment cost would be minimum
for technology insertion and refreshment during the life of a space system. It is observed that the proposed “Affordable”
and “Resilient” acquisition and sustainment strategies and the corresponding proposed approaches for achieving MIAC
and MISC are indeed aligned with the SMC’s vision on “Affordable” and “Resilient”. Section 5 discusses an innovative
approach to achieve “Program Resiliency” by aligning SMC’s vision with the Four BBP 3.0 Initiatives that focus on
affordable, technology insertion and refresh, and MOSA [Ref. 21].
5. Description of the Proposed SMC-OA and Implementation of SMC-OSAP
Section 5 describes a recently proposed OSAP that addresses the alignment between BBP 3.0 and SMC’s vision [Ref. 21].
This newly proposed OSAP is currently being recommended to SMC, and it is also referred to as SMC-OSAP in this paper.
MOSA
Naval Open Architecture (NOA) Principles
Increase Competition
NOA Business Principles:
•Life Cycle Affordability
•Encourage Competition
and Collaboration
NOA Technical Principles:
•Modular Design & Disclosure
•Total System Performance,
Interoperable Joint Warfighting
Apps, Secure Info Exchange
•Re-Usable Software
DOD
MOSA (OSA) Is an
integral part of all
Acquisition Strategies
to achieve affordable,
evolutionary, and
joint combat
capability
Figure 8. Description of MOSA and NOA Principles and Benefits [Ref. 13]
Proc. of SPIE Vol. 9469 946907-6
Downloaded From: http://proceedings.spiedigitallibrary.org/ on 05/26/2015 Terms of Use: http://spiedl.org/terms
MosA is an Nronment
Integral pan of an Employ Modul r Des' n
iyMievol
utiona ey, nter/ res
Vision Principles
capaldtlty
lì(IteÍilti
Chan,
ed Tdal Ownership Cod
ed (.vcleiime
mg Joint Integrated
Ri+k Mitigation
Business litechnica
Indicators
To achive “Program Resiliency”, the following OA principles are being recommended to SMC, (hence it is referred to as
SMC-OA
10
) in addition to existing MOSA and NOA principles, to align the Four BBP 3.0 initiatives with SMC’s vison
on “Affordable” and “Resilient” acquisition and sustainment strategies (described in Section 4 above) [Ref. 21]:
– SMC-OA Principle #1: Affordable TOC/LCC approach to achieve optimum (or lowest) acquisition and sustainment
cost over the life of a space system. This is a “Business” principle that depends on the acquired system, which is
acquiring as an NSSD or MSI effort:
– SMC-OA Principle #1a: Minimize TOC to achieve the lowest cost for NSSD effort.
– SMC-OA Principle #1b: Minimize LCC to achieve the lowest cost for SMI effort.
– SMC-OA Principle #2: Increase open source competition to achieve “Affordable” and “Resilient” Acquisition
strategies described in Section 4. This is also a “Business” principle.
– SMC-OA Principle #3: TeAg approach to achieve Affordable” and “Resilient” sustainment strategies described in
Section 4. This is a “Technical” principle.
The benefits of the proposed additional SMC-OA principles are captured in the upper left-hand corner of Figure 9, namely,
“reduce acquisition cost” by increased open source competition, and “reduce sustainment cost” by making technology
refresh/insertion independent of technology changes. Figure 9 also describes an approach for implementing the SMC-OA
principles, namely “Proposed SMC-OSAP” for achieving “Program Resiliency” [Ref. 21]. The proposed SMC-OSAP
integrates SMC-OA principles with the combined “Existing MOSA and NOA Principles”. The high-level integrated
approach is shown in the lower-half of Figure 9 with “color code” to differentiate among SMC-OA, NOA and MOSA, and
letter “B” and “T” designation to distinguish between “Business” and “Technical” principles, respectively.
Figure 9. Proposed Implementation of SMC-OSAP for Achieving “Program Resiliency”
As illustrated in Figure 9, the proposed SMC-OSAP
incorporates the changes due to technology
refreshment and insertion by integrating appropriate
business and technical principles to achieve both BBP
3.0 Initiatives and SMC’s vision. A Business Case
Study for acquisition and sustainment efforts can be
constructed and conducted to determine if the
proposed SMC-OSAP is the most economical way for
acquiring the required capabilities. In practice, the
business case selected should make “Affordable”
10
Note that the three new SMC-OA principles are being recommended to SMC, and SMC has not adopted the proposed principles yet.
SMC Vision
Achieve Resilient
and Affordable for
Acquisition and
Sustainment of
All Future Space
Systems
SMC-OA Principles Benefits
LCC/TOC Affordability
Open Source Competition
Technology Agnostic
Reduce acquisition
cost
Reduce sustainment
cost
Sustainment cost is
independent of
technology changes
Newly Proposed OA Principles
Acronym:
SMC = Space and Missile Systems Center
OA = Open Architecture
MOSA = Modular Open System Approach
OSA = Open System Architecture
OSAP = Open System Approach
LCC = Life Cycle Cost
TOC = Total Ownership Cost
B = Business Principle
T = Technical Principle
Existing MOSA (or OSA) and NOA Principles
New-OA Our Newly Proposed Principle
MOSA
Naval Open Architecture (NOA) Principles
Increase Competition
NOA Business Principles:
•Life Cycle Affordability
•Encourage Competition
and Collaboration
NOA Technical Principles:
•Modular Design & Disclosure
•Total System Performance,
Interoperable Joint Warfighting
Apps, Secure Info Exchange
•Re-Usable Software
DOD
MOSA (OSA) Is an
integral part of all
Acquisition Strategies
to achieve affordable,
evolutionary, and
joint combat
capability
Modular Design and
Design Disclosure
Employ Modular Design
Total Sys Performance,
Interoperable Joint
Warfighting Applications,
Secure Info exchange
Select Open Standards
Reusable Application
Software
T1
T2
T5
T6
Certify Conformance
Establish Enabling
Environment
Encouraging Competition
and Collaboration
B2
B1
Designate Key Interfaces
MOSA
Naval OA
LCC Affordability
B3
B4
T3
T4
Establish Enabling
Environment
B5
Technology Agnostic
T7
TOC Affordability
B6
Open Source
Competition
B7
SMC-OA
Technology
Driver
Business Technical
Incorporate
Changes
B1 –B7 = Business Principles
T1 –T7 = Technical Principles
Proposed SMC-OSAP
New-OSAP
Figure 10. Framework for Constructing a Business Case for SMC-OSAP
Acquisition Business
Case Study
−Identify CTE and associated Key
Open Sub-Systems (KOSS)
−Perform Openness Trade Study
on “Identified” KOSSs
−Select the KOSSs that Make the
most Business Sense in terms of:
−Increased competition
−Achieve Minimum Acquisition
Cost (MIAC), i.e., lowest LCC/
TOC
SMC-
OSAP
Sustainment Business
Case Study
−Identify Key Open Sub-Systems (KOSS)
−Develop Technology Roadmaps for the Identified
KOSS
−Perform Sustainment Cost Analysis on “Identified”
KOSSs
−Select the KOSSs that Make the most Business
Sense in terms of Minimum LCC/TOC over the life
of the system and related technology roadmaps
−Achieve Minimum Sustainment Cost (MISC),
i.e., lowest LCC/TOC
Acquire a System That
Aligns with BBP 3.0
and SMC Vision
Sustain a System That
Aligns with BBP 3.0
and SMC Vision
SMC’s
Vision BBP 3.0
SMC-
OSAP
Proc. of SPIE Vol. 9469 946907-7
Downloaded From: http://proceedings.spiedigitallibrary.org/ on 05/26/2015 Terms of Use: http://spiedl.org/terms
and “Resilient” sense as defined in Section 4, and a minimum saving of 5 - 10% over the life of the program as compared
to non-OA approach is recommended
11
. Figure 10 describes a high-level framework for constructing a Business Case
Study that can align the Four BBP 3.0 Initiatives with SMC’s vision to achieve affordable and resilient
acquisition/sustainment of a space system. The alignment processes to achieve “Program Resiliency” are discussed in the
following subsections.
5.1 Alignment SMC’s Vision with Four BBP 3.0 Initiatives for Achieving “Affordable” and “Resilient” Acquisition
Figures 11 and 12 present flow diagrams that describes an approach on how to develop an acquisition strategy (using the
above recommended SMC-OSAP) that
can align SMC’s vision with BBP 3.0.
The alignment goals are to Increased
Open Source Selection (IOSS) and
achieve affordable acquisition. Due to
the page limitation, a high-level
description is provided to help the reader
understand the alignment concept. The
key steps are: (i) Perform architecture
design and system decomposition, and
determine the KOSSs and associated
System Interfaces that meet warfighter
needs - The KOSSs identified using
SMC-OSAP are referred to as SMC-OA
KOSSs; (ii) Evaluate SMC-OA KOSS
and Interface using DOD recommended
KOSS tools (see Figure 11): (iia) KOSS
evaluation is performed over the life of
the system using program capability roadmaps, (iib) Identify and select a business case for the selected key interfaces to
ensure the selected SMC-OA KOSS and associated interfaces are good candidates for IOSS and affordable acquisition;
(iii) Based on the selected business case, develop acquisition strategy to achieve IOSS - Perform the cost analysis on the
selected SMC-OA KOSS and interfaces internal to the system that minimize TOC/LCC over the life of the system and
consolidate the selected business case to ensure
system affordability; and (iv) Document SMC-
OA activities in the government owned OSMP.
The steps (ii) and (iii) are used to align the BBP
3.0 Initiatives with SMC’s vision. The
Acquisition Strategy derived from this process is
based on the “business-driving” SMC-OA KOSS
components to ensure IOSS and affordable
system acquisition. In Figure 11, the Program
Capability Roadmap identifies the driving
parameter performance capabilities needed for
Enabling Technology Elements (ETEs) that drive
Critical Technology Elements (CTEs), and the
Technology Roadmap identifies all CTEs and
associated ETEs that are the underlying
performance parameters that drive CTE maturity,
and the “***” notation means that the term
“Resilient Acquisition” is used in the text of IOSS. The terms “SMC-OA Resilient Design” and “SMC-OA Affordable
Design,” shown in Figure 11, describe design approaches that employ the SMC-OA KOSS in the space system design to
achieve Affordable and Resilient Acquisition goals shown in Figure 12. The alignment between the Four BBP 3.0
Initiatives and SMC’s vision will occur when the SMC-OA KOSS Selection Goals # 1 and #2 are strictly enforced.
11
The saving quoted based on the estimate using cost data, CTEs, and capability roadmap data of a DOD program for acquiring a weapon system.
Figure 11. SMC-OSAP Flow Diagram for Affordable and Resilient Acquisition
Figure 12. SMC-OA KOSS Design Concept for Achieving Affordable
and Resilient Acquisition Strategy
SMC-OA KOSS Concept for Affordable and Resilient Acquisition
Data Right To Ensure Increased Open Source
Selection and Affordable Acquisition
Unlimited Rights
Government Purpose Rights
SBIR/STTR
Commercial Rights
Specially Negotiated Rights
Limited Restricted Rights
Space
System
Sub-
System 1
Sub-
System 2
Component 1.1
Component 2.1
Component 2.2
Component 3.2
SMC-OA KOSS 1
SMC-OA KOSS 2
Key Open Component 1
Key Open Component 2
SMC-OA KOSSs Selection Goal #2: Identify
Business Case with Increased Open Source
Selection
SMC-OA KOSSs Selection Goal #1:
Affordable System Acquisition
Sub-
System 3
Component 1.2
Component 3.1
SMC-OA Key Interface
SMC-OA Key Interface
SMC-OA Key Interface
SMC-OA Key Interface
System Components Need to be
Transitioned to “Open”
Components at Pre Milestone C
Denote Open Interface
Closed Interfaces
DOD NAVAIR
KOSS
TOOL
*Capability Roadmap identifies the driving parameter performance capabilities
needed for Enabling Technology Elements (ETEs) that drive the Critical
Technology Elements (CTEs)
**Technology Roadmap identifies all CTEs and associated ETEs that are the
underlying performance parameters that drive CTE maturity.
***Resilient Acquisition is defined as “Increased Open Source Selection”
AFRL Vision
DOD NAVAIR
KOSS
TOOL
Identify &
Rank KOSS
Modular Design and
Design Disclosure
Employ Modular Design
Total Sys Performance,
Interoperable Joint
WarfightingApplications,
Secure Info exchange
Select Open Standards
Reusable Application
Software
T1
T2
T5
T6
Certify Conformance
Establish Enabling
Environment
Encouraging Competition
and Collaboration
B2
B1
Designate Key Interfaces
MOSA
Naval OA
LCC Affordability
B3
B4
T3
T4
Establish Enabling
Environment
B5
Technology Agnostic
T7
TOC Affordability
B6
Open Source
Competition
B7
SMC-OA
Technology
Driver
Business Technical
Incorporate
Changes
B1 –B7 = Business Principles
T1 –T7 = Technical Principles
SMC-OSAP
Government/Contractor Owned
System Architecture Design
•MOSA Modular Design
•NOA Interoperability Design
•SMC-OA Resilient Design
•SMC-OA Affordability Design
System
Decomposition
Sub-System
Decomposition
Sub-System
Components
Program Technology
Roadmap**
Program Capability
Roadmap*
SMC Vision
USAF Vision
Acquisition
Business Case Achieve
Affordable
& Resilient***
Acquisition
SMC Perspective on Costs
Historical
Cost
Information
Projected
Cost
Information
Government
Data Right
Information
Define
Acquisition
Strategy
No
Yes
Start
End
Pre-MS A
Goal:
Align BBP 3.0 and SMC Vision To:
•Increase Open Source Selection
•Affordable System Acquisition
Pre-MS C
Increased System Design Maturity
Warfighter
Capability
Requirements
Risk
Management
Proc. of SPIE Vol. 9469 946907-8
Downloaded From: http://proceedings.spiedigitallibrary.org/ on 05/26/2015 Terms of Use: http://spiedl.org/terms
5.2 Alignment SMC’s Vision with Four BBP 3.0 Initiatives for Achieving “Affordable” and “Resilient”
Sustainment
Figures 13 and 14 describe the flow diagrams
for development of a sustainment strategy
using SMC-OSAP that can align SMC’s
vision with the Four BBP 3.0 Initiatives. The
alignment goals for the system sustainment
are to select SMC-OA KOSSs that can
achieve (a) “Affordable” system sustainment,
and (b) “Resilient” sustainment cost that is
independent of technology changes. The key
steps to achieve the alignment are: (i)
Perform sustainment cost analysis on the
selected SMC-OA KOSS and associated
interfaces – The selected interfaces are
internal to the system that minimize the
TOC/LCC over the life of the system and related program capability roadmaps; (ii) Consolidate and refine the identified
business case selected earlier to ensure sustainment cost is independent of technology changes and the system sustainment
cost is affordable; (iii) For the selected KOSSs that are not “Open”, provide an SMC-OA KOSS mitigation approach for
each instance of data rights being asserted at less than
GPR (see Figure 14); (iv) Develop SMC-OA milestones
to achieve “Affordable and Resilient Sustainment”
strategies described in Section 4 – SMC-OA roadmap
captures the transition from the initial design with
Proprietary Components to Production & Deployment
Design with Open Components; and (v) Document
Government owned SMC-OA activities in OSMP.
Similarly, the “SMC-OA Resilient Design” and “SMC-
OA Affordable Design” shown in Figure 13 employ the
SMC-OA KOSS design concept for Affordable and
Resilient sustainment shown in Figure 14. Again, the
alignment between the Four BBP 3.0 initiatives and
SMC’s vision will occur when the SMC-OA KOSS
Selection Goals #3 and #4 described in Figure 14 are
strictly enforced. The SMC-OA KOSS and Associated Data Rights should be applied to sustainment phase if the refined
business case makes sense, and as mentioned earlier, a minimum saving of 5 - 10% over the life of the program as compared
to non-OA approach is recommended.
5.3 Impacts of SMC-OSAP on PTBF: Achieving Resilient PTBF
A business case that makes sense is the key driving force to apply SMC-OSAP in the development of Affordable and
Resilient Acquisition and Sustainment strategies described in Section 4. The strategies must incorporate the SMC-OSAP
milestones into existing DAS milestones to ensure proper “Resilient” PTB components are available at each key MDD
(Materiel Development Decision) point for the MDD authorities to act upon. Below is a description of SMC-OA activities
that are recommended at each DAS milestone:
• MS A: Document Resilient PTB components that capture Initial Design with KOSS Components and CTE identified
for Open Source Competition – Resilient PTB components required at MS A.
• MS B: Document Resilient PTB components that capture EMD Design with associated risks for the Transition Design
for Proprietary Components – Resilient PTB components required at MS B.
• MS C: Document Resilient PTB components that capture Production & Deployment Design with Open Designs for
all Proprietary Components identified at MS A – Resilient PTB components required at MS C.
• Document all SMC-OSAP activities at each milestone in OSMP (Open System Management Plan), including OA
activities, PTB components, and risks associated with the transition from the initial design with Proprietary
Components to Production and Deployment Design with Open Components.
Figure 13. SMC-OSAP Flow Diagram for Affordable and Resilient Sustainment
Figure 14. SMC-OA KOSS Design Concept for Achieving
Affordable and Resilient Sustainment Strategy
Data Right To Ensure Increased Open Source
Selection and Affordable Acquisition
Unlimited Rights
Government Purpose Rights (GPR)
SBIR/STTR
Space
System
Sub-
System 1
Sub-
System 2
Component 1.1
Component 2.1
Component 2.2
Component 3.2
SMC-OA KOSS 1
SMC-OA KOSS 2
Key Open Component 1
Key Open Component 2
KOSSs Selection Goal #3:
Affordable System Sustainment
Sub-
System 3
Component 1.2
Component 3.1
SMC-OA Key Interface
SMC-OA Key
Interface
SMC-OA Key Interface
SMC-OA Key Interface
The Transitioned Components with
open interfaces Must Meet The
following Business Goals for
Sustainment Phase:
-Replacement cost is High
-Replacement frequency is High
Denote Open Interface
Transition to Open Interfaces Commercial Rights
Transitioned to GPR
Specially Negotiated Rights
Transitioned to GPR
Limited Restricted Rights
Transitioned to GPR
DOD NAVAIR
KOSS
TOOL
KOSSs Selection Goal #4:
Technology Agnostic, i.e., the KOSS and
Associated Open Interfaces are Selected
Such that the Sustainment Cost is
Independent of Technology Changes
SMC Vision
*SEMP is provided by the selected Contractor + Government owned SEP
**OSMP is provided by the selected Contractor + Government owned OSMP
***Resilient Sustainment is defined as “Technology Agnostic” for Selected KOSS
DOD NAVAIR
KOSS
TOOL
Identify &
Rank KOSS
Modular Design and
Design Disclosure
Employ Modular Design
Total Sys Performance,
Interoperable Joint
WarfightingApplications,
Secure Info exchange
Select Open Standards
Reusable Application
Software
T1
T2
T5
T6
Certify Conformance
Establish Enabling
Environment
Encouraging Competition
and Collaboration
B2
B1
Designate Key Interfaces
MOSA
Naval OA
LCC Affordability
B3
B4
T3
T4
Establish Enabling
Environment
B5
Technology Agnostic
T7
TOC Affordability
B6
Open Source
Competition
B7
SMC-OA
Technology
Driver
Business Technical
Incorporate
Changes
B1 –B7 = Business Principles
T1 –T7 = Technical Principles
SMC-OSAP
Government Owned
System Architecture Design
•MOSA Modular Design
•NOA Interoperability Design
•SMC-OA Resilient Design
•SMC-OA Affordability Design
SEP/SEMP*
(System Engineering Plan)
OSMP**
(Open System Mgmt Plan)
SMC Program
Office Input
Sustainment
Business Case Achieve
Affordable
& Resilient***
Sustainment
SMC Perspective on Costs
Historical
Cost
Information
Projected
Cost
Information
Government
Data Right
Information
Define
Sustainment
Strategy
No
Yes
Start
End
Update
System
Decomposition
Sub-System
Decomposition
Sub-System
Components
Update
Update
Update
Update
Goal: Align BBP 3.0 and SMC Vision by:
•Selecting KOSSs that are Technology
Agnostic
•Achieving Affordable Sustainment
Obsolescence
Risk Relative Cost
Of Change
Update
Risk
Management
Warfighter
Capability
Requirements
Contractor
Input
Program Capability
Roadmap*
Proc. of SPIE Vol. 9469 946907-9
Downloaded From: http://proceedings.spiedigitallibrary.org/ on 05/26/2015 Terms of Use: http://spiedl.org/terms
Initial
Capabilities
Document.
Materiel
Development
Decision
Materiel
Solution
Analysis
Phase
Requireree.t
Authority
Rev lew of ASA
Res utts
Draft
Capability
Development
Document
Leaentl
O= Decision Point
= Milestone Decision
fl= Requirements Document
= Requirements Authority
Review
[l
Technology Maturation &
Risk Reduction Phase
N.
Capability
Development
Document.
Or Equivalent Approved /Validated Requirements Document.
Engineering & Manufacturing
Development Phase
N
Capability
Production
Document' Production 8
Deployment Phase
Operations & Sti
Phase
As shown in Figure 15, Resilient PTB components are influenced by the SMC-OA activities described above, and varied
with system acquisition phases. This figure captures the impacts of SMC-OSAP on the Resilient PTB components. In
addition to the TB components shown in Figure 3, the Resilient PTB components have SMC-OA artifacts resulting from
the SMC-OA activities listed above. As an example, at Milestone A, in addition to the TB artifacts described in Figure 3,
the Resilient PTB components also include KOSS identification report, CTE identification report, Proprietary component
identification report, MOSA (or OSA) assessment report, and draft OSMP report.
Figure 15. Resilient PTB Components in the Context of SMC-OA, DAS, DoDAF and JCIDS
6. Impacts of IPM on Resilient PTBF Using Combined DAS, JCIDS, DODAF and SMC-OSAP
This section extends Section 3 to include an IPM approach that employs a combined SMC-OSAP/DAS/JCIDS/DODAF
process in the IPM approach (or SMC-OSAP/DAS/JCIDS/DODAF-IPM) to integrate and synchronize the five-KPEs.
The definitions of the five-KPEs in the SMC-OSAP/DAS/JCIDS/DODAF-IPM context become:
i. PRes addresses system and program requirements on open system design, program cost and program schedule.
ii. SAD addresses technical requirements on open system architecture and design using DODAF process and tools.
iii. PC addresses cost requirements on “Affordability” and “Resilient” using WBS (Work Breakdown Structure)/
Integrated Master Plan (IMP)/Cost models and tools.
iv. PS addresses requirements on program schedule using Integrated Management Schedule (IMS) process and tool.
v. PRis addresses risks associated with PRes, SAD, PC and PS.
The newly proposed SMC-OSAP/DAS/JCIDS/DODAF-IPM approach integrates and synchronizes the above five KPEs
by using the following recommended approaches:
SMC-OSAP system architecture design approach with support from DAS/JCIDS/DODAF to integrate technical (PRes)
and business (PC) objectives to develop baseline SAD, IMP, IMS and PRis using specialty MOSA System Engineering
(SE) processes and tools including but not limited to DODAF processes and tools, KOSS Tool [17], OA Assessment
Tool (OOAT) [18], and MOSA Program Assessment and Rating Tool (PART) [19].
Critical Chain Program Management (CCPM) process and tools to integrate and synchronize PRes, SAD, PC and PS
to identify “Program Critical Paths” and associated PRis.
Earned Value Management (EVM) process and tools to integrate and synchronize PRes, SAD, PC, PS and PRis.
Resilient PTB components for this case are influenced by the integrated SMC-OSAP/DAS/JCIDS/DODAF-IPM approach
and varied with system acquisition phases. Figure 16 captures the impacts of SMC-OSAP/DAS/JCIDS/DODAF-IPM
approach on the Resilient PTB components. Figure 16 shows that in addition to the Resilient PTB components shown in
Figure 15, the modified PTB components have both technical and programmatic artifacts resulting from the use of SMC-
OSAP/DAS/JCIDS-IPM approach. As an example, at Milestone A, in addition to the Resilient PTB artifacts described in
Milestone A Technical Baseline (MA-TA): Same definition as DAS + KOSS Identified + CTE Identified + Potential Proprietary Components
Identified* + MOSA (or OSA) Assessment Report + Draft OSMP Developed
Milestone B Technical Baseline (MB-TB): Same as DAS + KOSS Update 1 + CTE Update 1 + Status of “Proprietary Components
Transition to Open Components” + MOSA (or OSA) Assessment Report Update 1 + OSMP Update 1
Milestone C Technical Baseline (MC-TB): Same as DAS + KOSS Update 2 + CTE Update 2 + All Proprietary Components
Transitioned to Open Components + MOSA (or OSA) Assessment Report Update 2 + OSMP Update 2
Post-Milestone C Technical Baseline (PoMC-TB): Same as DAS + Waiver for Non-Open
Components + Final MOSA (or OSA) Assessment Report + Final OSMP Report
Operational & Deployment Technical Baseline
(O&D-TB): Same as DAS + Monitor Technology
Changes Status and Report on “Technology
Agnostic” Components
Proposed PTB Definition in the Context of DAS, JCIDS and SMC-OA
KOSS Identified
CTE Identified
Draft Gov’t Owned OSMP
Developed
KOSS Update 1
CTE Update 1
OSMP Update 1
Open Components
Potential Proprietary
Components
Identified
Gov’t Owned MOSA
(or OSA) Assessment
Report
MOSA (or OSA) Assessment Report Update 1
MOSA (or OSA) Assessment Report Update 2
OSMP Update 2
Proprietary Components
Transition to Open Components
KOSS Update 2 CTE Update 2
* These potential proprietary components
must transition to “open components” by
The end of Milestone B. If not, a waiver
must be submitted to PMO for approval.
Acronym:
KOSS = Key Open SubSystem
CTE = Critical Technology Element
OSMP = Open System Management Plan
Proc. of SPIE Vol. 9469 946907-10
Downloaded From: http://proceedings.spiedigitallibrary.org/ on 05/26/2015 Terms of Use: http://spiedl.org/terms
N
Initial
Capabilities
Document'
Materiel
Development
Decision
Materiel
Solution
Analysis
Phase
Requirmrents
Authority
Review of AoA
Results N
Draft
Capability
Development
Document
f
Lenentl
= Decision Point
= Milestone Decision
= Requirements Document
= Requirements Authority
Review
Technology Maturation 8
Risk Reduction Phase
Capability
Development
Document'
Or Equivalent Approved/Validated Requirements Document.
Engineering 8 Manufacturing
Development Phase
Capability
Production
Document' Production 8
Deployment Phase
Operations it Support
Phase
Ia =vom I
Figure 15, the modified Resilient PTB components also include reports on cost estimate, schedule estimate, critical path
identification, a list deliverables, and preliminary risk assessment.
Figure 16. PTB Components in the Context of SMC-OA, DAS, JCIDS and IPM
7. Resilient PTB Framework and Associated Key Components
Based on the Resilient PTB definitions given in the previous sections, Figure 17 illustrates a high-level process to generate
the required Resilient PTB components from
the five KPEs. The process starts at the ICD,
CDD and CPD documents and ends at
Performance Measurement baseline (PMB)
component, which is recommended as part of
the Resilient PTB components. PMB is defined
as the sum of the Schedule Baseline (SB) and
Earned Value Baseline (EVB). The key blocks
shown in this figure are the IPM and five-KPEs,
including PRes, SAD, PC, PS and PRis. A
detailed Resilient PTBF is now obtained by
decomposing the key blocks shown in Figure 17
into the “process” and “tool” blocks that are
required for generating the Resilient PTB
components. Figure 18 provides a detailed
decomposition of these key blocks into a PTBF
that can be used to generate the required Resilient PTB Components for a space system. The Resilient framework shown
in Figure 18 is color coded for differentiating among process, tool, Resilient PTB component, KPEs, and Derived Program
Component (DPCom). DPCom is defined as the component(s) that is/are derived from the KPEs. For example, the “Cost
Baseline (CB)” block shown in Figure 18 is a DPCom that is derived from the KPE block titled “PC”. Figure 18 shows
what processes and tools that are required to generate each Resilient PTB component, and that the PTB consists of a total
of “Nine” key Resilient TB components, namely, (i) TB Component #1: Key Requirements (both technical and
programmatic) captured by SE tool and SEP (System Engineering Plan), (ii) TB Component #2: SAD captured by DODAF
tool, (iii) TB Component #3: KOSS captured by OSAP tools and OSMP, (iv) TB Component #4: Deliverables/CDRLs
captured by SE tools and SEP, (v) TB Component #5: Program (both technical and programmatic) risks captured by Active
Risk Manager (ARM) tool and SEP, (vi) TB Component #6: PC captured by cost tool, (vii) TB Component #7: PS captured
by schedule tool, (viii) TB Component #8: Critical Path (CP) captured by PM tool, and (ix) TB Component #9: PMB
captured by PM tool.
Milestone A Technical Baseline (MA-TA): Same definition as DAS + SMC-OSAP + Cost Estimate + Schedule Estimate + Critical Path Identified +
Deliverables Identified + Preliminary Risk Assessment
Milestone B Technical Baseline (MB-TB): Same as DAS + KOSS Update + CTE Update 1 + Proprietary Components Transition to
Open Components Status + MOSA (or OSA) Assessment Report Update 1 + OSMP Update 1 + Cost Update 1 + Critical Path Update
1 + Deliverables Update 1 + Schedule Update 1 + Risk Assessment Update 1
Milestone C Technical Baseline (MC-TB): Same as DAS + + KOSS Update + CTE Update 2 + Proprietary Components Transition
to Open Components Status + MOSA (or OSA) Assessment Report Update 2 + OSMP Update 2 + Cost Update 2 + Schedule
Report Update 2 + Critical Path Update 2 + Deliverables Update 2 + Risk Assessment Update 2
Post-Milestone C Technical Baseline (PoMC-TB): Same as DAS + All Components Are
Open + Final MOSA (or OSA) Assessment Report + Final OSMP Report Cost Update 3 +
Schedule Report Update 3 + Critical Path Update 3 + Deliverables Update 3 + Risk
Assessment Update 3
Operational & Deployment Technical Baseline
(O&D-TB): Same as DAS + Monitor Technology
Changes and Report on “Technology Agnostic”
Components + Sustainment Cost Estimate +
Schedule Report + Critical Path + Deliverables
+ Risk Assessment
Proposed PTB Definition in the Context of DAS, JCIDS, SMC-OA, and IPM
KOSS Identified
CTE Identified
Draft Gov’t Owned OSMP
Developed
KOSS Update 1
CTE Update 1
OSMP Update 1
Open Components
Proprietary
Components
Identified
Gov’t Owned MOSA
(or OSA) Assessment
Report
MOSA (or OSA) Assessment
Report Update 1
MOSA (or OSA) Assessment Report Update 2
OSMP Update 2
Proprietary Components
Transition to Open Components
KOSS Update 2 CTE Update 2
Integrated Program Management
(IPM)
SMC-OSAP Design employs
MOSA, NOA and Newly
Proposed SMC-OA Principles
Standard Program
Management Practice (SPMP)
Critical Chain Program
Management (CCPM)
Earned Value
Management
System (EVMS)
Figure 17. High-Level Process for Constructing of Resilient PTBF
PMB Definition:
Schedule Baseline (SB) = Original approved time line for accomplishing the project objectives
Earned-Value Baseline (EVB) = Employ time line defined by IMS to establish EV (Earned-Value) cost and schedule performance plan
Performance Measurement Baseline (PMB) = Schedule Baseline (SB) + Earned-Value Baseline (EVB)
Program
Requirements
(PRes): TRD,
Interface Control
Document, etc
Program Schedule
(PS) Estimate
System Architecture
Design (SAD): AVs,
CVs, DIVs, OVs, PVs,
SvcVs, StdVs, SVs
ICD, CDD, CPD
Work Product List
(WPL)
Capability-to-
Requirement Mapping
Work Breakdown
Structure (WBS)
Program Cost
(PC) Estimate
PTB Components
Process
Input
Key Program Element
Derived Program Component
Output TB Component
Color Code
System Architecture
Development
IMP
Program Risks
(PRis): Cost,
Schedule,
Requirement, and
System Risks
IMS
Identify System Risks
Identify Program
Critical Paths
Cost Risks Identified
Integrated Program
Management
(IPM)
SMC-OA &
SE Process
EVMS
Process
CCPM
Process
OSA-SE
Tools
PM
Tools
EVMS
Tools
CCPM
Tools
Open &
Modular
Design
Risk
Tools Risk
Process
Standard PM
Process
Schedule Risks Identified
Schedule
Tracking Cost Tracking
Identify Requirement Risks
Risks
Captured
Risks
Mitigated
Start
End
Performance
Measurement
Baseline (PMB)
Identify CDRLs
Proc. of SPIE Vol. 9469 946907-11
Downloaded From: http://proceedings.spiedigitallibrary.org/ on 05/26/2015 Terms of Use: http://spiedl.org/terms
Figure 18. Proposed Resilient PTBF for Generating Resilient PTB Components
As discussed above, the Nine-key Resilient PTB components described in Figure 18 are influenced by SMC-OA strategies
for achieving “Program Resiliency”, DAS, JCIDS and DODAF and varied with the DOD acquisition phases, therefore
using the proposed PTBF presented in Figure 18 and the definitions of Resilient PTB components shown in Figure 16, we
have derived a matrix describing a systematic way to generate the desired Resilient PTB components that correspond to
the five-KPEs. Table 2(a) shows the matrix that captures the SE (System Engineering)/OSA/PM (Program Management)
processes/tools required to generate the desired PTB components. The matrix provides a recipe for how the Resilient PTB
components can be generated from the five KPEs using IPM approach for integrating the five-KPEs with SE process/tools,
Cost tools, DODAF tools, OSA process/tools, Risk Management process/tools, CCPM and EVMS process/tools. Table
2(a) also captures (i) the processes and tools that are not currently available to the system architect by using “Yellow”
boxes, and (ii) existing TB components by using “Red-Line” box. The “Yellow” boxes show the required SE/OSA/PM
processes/tools that the system architect needs to develop for generating the corresponding Resilient PTB components. As
an example, Table 2(b) shows the zoom-in of a “Yellow” box titled “MOSA PART Process” and this means that presently
the system architect does not have this “MOSA PART Process” available to guide him/her in the generation of the
recommended PTB component titled “MOSA/OSA Program Assessment and Rating”. Table 2(a) along with the
recommended SMC-OSAP provide a comprehensive recipe to generate Resilient PTB components that meets SMC’s
vision, and aligns with the Four BBP 3.0 Initiatives (i)-(ii)-(iv)-(vi). Due to the page limitation, we are not able to provide
the matrix with legible font in Table 2(a), we encourage the readers to send a request to us for a softcopy of the matrix.
Another aspect that is important to the government acquisition authorities as well as system architect is “who owns what?”,
and Table 3 addresses this issue by providing a preliminary check list to show the technical and programmatic features of
a comprehensive reference “Government” and “Contractor” “owned” PTB components. Table 2(a) along with Table 3 are
being recommended to SMC for consideration as the reference Resilient PTB components of future space systems.
8. Conclusions, Recommendations, and Way-Forward
The paper has reviewed existing views on TB and discussed the differences between TB and PTB, and presented an
innovative approach for the development of a Resilient PTBF that can provide a recipe for how the Resilient PTB
components can be generated from KPEs using an integrated SMC-OSAP/DAS/JCIDS/DODAF-IPM approach. Based on
the proposed Resilient PTBF shown in Figure 18, the paper has provided matrices shown in Tables 2 and 3 that have
captured the required tools/processes to generate a comprehensive set of PTB components and a recommended set of U.S.
DOD “owned” PTB, respectively. In addition, Table 3 also provides a recommended set of contractor “owned” PTB. In
addition, the paper has also described the affordable and resilient acquisition and sustainment strategies that would
DODAF Tools
Program Risk
(PRis) Captured By
ARM Tool and SEP
Program
Requirements
(PRes)
Program Schedule
(PS) Estimate
System Architecture
Design (SAD)
OSAP-SE Process Risk Management
Framework
SAD Captured by
DODAF Tool
Risk Management
Tools
OSAP Tools
System
Engineering
(SE) Tools Program Risk
(PRis)
Work Product List
(WPL)
OSAP Process KOSS Captured by
OSAP Tool & OSMP
Work Breakdown
Structure (WBS)
SE Process
Program Cost
(PC) Estimate
Identify Critical
Paths (CPs)
Resolve Resource
Conflicts
CCPM Process
SE and Cost Tools
Perform Cost and
Schedule
Performances
EVMS Tool
Track Critical Paths
Integrate Cost with
The Technical and
Schedule Objectives
EVMS Process
Performance Measurement
Baseline (PMB) Captured
By PM Tool
Earned-Value
Baseline (EVB)
Schedule
Baseline (SB)
Process
Tool
Key Program Element
Derived Program Component
Technical Baseline Component
Color Code
TB Component #3
TB Component #2 TB Component #5
Program Cost
(PC) Captured By
Cost Tool Program Schedule
(PS) Captured By
Schedule Tool
TB Component #6
TB Component #7
TB Component #9
Acronym:
OSA = Open System Approach
KOSS = Key Open Sub-System
ARM = Active Risk Manager
PM = program Management
SE = System Engineering
Key Requirements
Captured by
SE Tool and SEP
TB Component #1
Deliverables or
CDRLs Captured by
SE Tool and SEP
TB Component #4
Start
End
Critical Path (CP)
Captured By PM
Tool
TB Component #8
LCC / TOC
Cost
Baseline (CB)
SE Tool
Proc. of SPIE Vol. 9469 946907-12
Downloaded From: http://proceedings.spiedigitallibrary.org/ on 05/26/2015 Terms of Use: http://spiedl.org/terms
Table 2(a). A Matrix Describing the Proposed Resilient PTBF
Table 2(b). Zoom-In of the Resilient PTB Components for the SAD Program Element
SE OSA PM SE OSA PM
Techical
Requirements
Capability-to-Requir ement
Mapping
Excel Spreadsheet
or DOOR
Technical Requirement Documents
(TRDs) and Interface Control
Document (InCD)
TRDs are derived from ICD, CDD
and CPD
JCIDS, DOD-
5000.02
Work Breakdown
Structure (WBS)
(Program + Technical)
Requirements-to-Task
Mapping
Excel Spreadsheet
List of Tasks and Subta sks ca ptured
in WBS
Gov't owned WBS at Program
Level
JCIDS, DOD-
5000.02
Work Product List
(WPL)
WBS-to-WPL Mapping Excel Spreadsheet List of Work Products
The work products must achieve
program objectives
System Engineering
Management Plan
(SEMP)
SEMP Report Owned by Contractor Team
JCIDS, DOD-
5000.02
System Engineering
Plan (SEP)
SEP Report Owned by Government Team
JCIDS, DOD-
5000.02
Draft Information
Support (IS)
MS Word IS Report Owned by Government Team
JCIDS, DOD-
5000.02
Test and Evaluation
Plan (TEMP)
VCRM and testing
Processes
TEMP Report
Owned by both Contractor and
Government Teams
JCIDS, DOD-
5000.02
Syatem Threat
Assessment Report
DOD Threat Assessment
Process
STAR Report Owned by Government Team
JCIDS, DOD-
5000.02
DD Form 1494 Spectrum Management
Analysis /
Simlation tools
DD Form 1494 submiss ion Owned by Government Team
JCIDS, DOD-
5000.02
Acquisition Program
Baseline
MS PPT or Excel
Sptreadsheet
APB Report Owned by Government Team
JCIDS, DOD-
5000.02
Program Deliverables WPL-to-CDRL Mapping Excel Spreadsheet List of CDRLs
CDRLs are identified from WPL
(Work Product List)
Program Reviews and
Accomplishment
Events
Planning process :
Mapping Program and
tasks and requirements
on key milestones
Excel Spreadsheet
(1) list of program revi ews (PDR, SDR,
CDR, etc.), and (2) Program
accomplishment events (e.g.,
subsystem delivery, complete
integration, complete PDR, etc)
Program Entrance and Exit
Criteria can help to i dentify
program reviews and
accomplishment events
Requirement
Baseline
Identify the baseline
requirements from
ICD/CDD/CPD/TRD
Excel Spreadsheet
or DOOR
List of System and assoc iated
subsystem requirements basel ine
derived from TRD
Baseline technical requirements
used for program costing a nd
scheduling
SMC-S-001
(2013), Section
3.2.1
Functional
Architecture Baseline
DODAF Views
SMC-S-001
(2013), Section
3.2.2
Allocated Baseline DODAF Views
SMC-S-001
(2013), Section
3.2.3
Design Release
Baseline
DODAF Views
SMC-S-001
(2013), Section
3.2.4
Product Configuration
Baseline
DODAF Views
SMC-S-001
(2013), Section
3.2.5
Transition &
deployment Baseline
DODAF Views
SMC-S-001
(2013), Section
4.1.7
Supportability
Baseline
Identify the baseline
requirements from
ICD/CDD/CPD/TRD
DODAF Views
SMC-S-001
(2013), Section
4.1.8
Disposal Baseline
Identify the baseline
requirements from
ICD/CDD/CPD/TRD
DODAF Views
SMC-S-001
(2013), Section
4.1.9
Mission Critical Fault
Analysis (MFCA)
Baseline
Identify the baseline
requirements from
ICD/CDD/CPD/TRD
Mission Cri tical Fault Anal ysis
(MFCA) Report
Baseline for misi ion cri tical
faults
SMC-S-001
(2013), Section
4.1.10
System Architecture
Design (SAD)
Architectural Design us ing
DOD Architecture
Framework (DoDAF).
DODAF 2.02
DODAF Views
Gov't team owns OV's and other
views specified in JCI DS CJCSI
3170.01H
DODAF 2.02
OSA or MOSA
Program Assessment
and Rating
MOSA
PART
Process
DOD MOSA
PART Tool
Assessment of MOSA (or OSA)
Implementation results presented i n
OSMP
MOSA PART Tool is the MOSA
Program Assessment and Rati ng
Tool to assess the
implementation of MOSA
throughout acquisiti on life cyc le
Open Architecture
Rating
NOA OAAT
Process
DOD OAAT
Open architecture asses sment
results presented in OSMP
OAAT is the Open Architeture
Assessment Tool to assess the
openess of the architecture
implementation solution
throughout acquisiti on life cyc le
Key Open Sub-System
(KOSS)
KOSS
Process
NOA-Industry
KOSS Tool
List of KOSS presented in OSMP
KOSS Tool is the Key Open Sub-
System Tool to select the key
subsystems that shoul d be made
"open" throughout acquisition
life cycle
Critical Technology
Element (CTE)
KOSS
Process
NOA-Industry
KOSS Tool
List of CTE presented in OSMP
A program Technology Roadmap
must be developed to capture
these CTEs.
Sub-system Open /
Proprietary Interfaces
KOSS
Process
NOA-Industry
KOSS Tool
List of potential Key Open and
Proprietary Intefaces pres ented in
OSMP.
The identified Proprietary
Interfaces must be transiti on to
fully open interface at pos t
Milestone B.
Open System
Management Plan
(OSMP)
Capture Key OSA
Requirements, OSA
Processes/Tools,
KOSS/Open Interface Risks
and Activities
MS work, Excel
Spread Sheet
OSMP Report
Gov't owned OSMP at Program
Level
Integrated Master
Plan (IMP)
Standard IMP Process Excel Spr eadsheet
IMP with (1) Program Descri ption
Section, (2) Process Section, a nd (3)
Product Section
IMP should descri be required
processes to get to the required
products for the program
Estimate Task
Duration
Standard Task Estimati on
Process
PERT Tool or Excel
Spreadsheet
Detailed time-dependent Tasks List
Standard process us es PERT
(statistical -based) , or Del phi
(concensus-based) or hi stori cal
data to estimate the task
duration
Integrated Mater
Schedule (IMS)
Standa rd IMS Proces s
Gantt Charts or
Network Diagram
or Time Scale Logic
Diagram
IMS with (1) all IMP components, (2)
Task oriented schedule, and (3)
Deatiled time depenedent
IMS should provide tas k
oriented schedule with detailed
time-dependent
Critical Path Estimate Standard CCPM Process
Gantt Charts or
Network Diagram
or Time Scale Logic
Diagram
A list of contiguous pa th of activi ties
in IMS havingthe longest total
duration
Critical path defi nes the
minimum duration of the
program
Performance
Measurement
Baseline (PMB)
PMB process Excel Spreadsheet
Schedule Baseline + Earned Val ue
Baseline (EVB)
EVB is defined by IMS to
establish EV cost an d schedule
performance plan
Hardware (HW) Cost
Software (SW) Cost
IV&V cost
Manufacturing Cost
Maintenance cost
System Engieering
Cost
Open System
Approach (OSAP) Cost
R&D Cost
Disposal Cost
PM Cost Including
Planning, Managing,
Excecuting, etc.
Life Cycle Cost (LCC)
Total Ownership Cost
(TOC)
Requirements Risk
KOSS Risk
CTE Risk
System Design HW
Risk
System Design SW
Risk
Integration Risk
Program Risks
including
Requirements,
System Design,
Critical Path, Cost,
Schedule,
Manufacturing,
Sustainment, etc
Risk Register@ or
ARM (Active Risk
Manager)
Proram Risk with Scori ng Tables for
Risk Impact / Consequence. The Risks
are tied with Pres, SAD, PC and PS.
Program Cost and Schedule ca n
help to identify risks asso ciated
with technical requir ements.
Program
Requirement
(PRes): TB
Components #1
and #4
System
Architecture
Design (SAD): TB
Components #2
and #3
Key Program
Element
PTB Product / Artifact
Resilient Program Technical Baseline Development Framework - Preliminary
SMC/DOD
Standard
PPT and Excel
Spread Sheet,
Popkin, Rational
Rose, etc
Requirement decoposition
and DODAF framework.
DODAF 2.02 and JCIDS
CJCSI 3170.01H
instructions
Capture Key Requirements,
SE Processes/Tools,
Requirement/Program
Risks and Activi ties
MS Word, Excel
Spread Sheet
MS Word, Excel
Spread
Sheet/VCRM Tool
DODAF views specified in JCI DS
CJCSI 3170.01H
Process
Tool
Remark
Resilient PTB
Component
Risk
Management
Guide For DOD
Aaquisition, 6th
Edition (V. 1.0),
Aug 2006
DOD OSA,
Contract
GuideBook for
PM, V1.1, May
2013
DOD Scheduling
Guide For PM,
Oct 2001
PMBOK@ Guide
Program Risk
(Pris): TB
Component #5
Program Cost
(PC): TB
Component #6
Standard Cost Estimate
Process + Cost Estimate
for Implementing OSA
Strategies
COCOMO Tool or
Revised Ada
COCOMO Tool or
RCA PRICE or SLIM
Tool
(1) LLC tied to OSA Strategy, System
Design, Program Requirements and
Risks or (2) TOC tied to OSA Strategy,
System Design, Program
Requirements and Risks
LLC is tied to SMI efforts and
TOC is tied to new space
systems development
Risk+ or TRIMS,
Crystal Ball
Analysis Tool,
Risk Taxonomy,
Customized Tickle
List, etc
Risk & Op Walks or
Factory/Assembly Line
Walks or Contrac tor /
Supplier Visit, or Li sten to
PM and Chief Engineers or
Look at the Program
Indicators su ch as
Schedule Float, EV Data,
Technical Requirements,
etc
Risk Taxonomy is us ed to guide
the thought process to analyze
risks
Program Schedule
(PS): TB
Component #7,
#8, and #9
SE OSA PM SE OSA PM
Mission Critical Fault
Analysis (MFCA)
Baseline
Identify the bas eline
requirements from
ICD/CDD/CPD/TRD
Miss ion Cri tical Fault Anal ysis
(MFCA) Report
Basel ine for misi ion cr itica l
faults
SMC-S-001
(2013), Secti on
4.1.10
System Architecture
Design (SAD)
Architectura l Design us ing
DOD Architecture
Framework (DoDAF).
DODAF 2.02
DODAF Views
Gov't team owns OV's an d other
views s pecified in JCIDS CJCSI
3170.01H
DODAF 2.02
OSA or MOSA
Program Assessment
and Rating
MOSA
PART
Process
DOD MOSA
PART Tool
Assess ment of MOSA (or OSA)
Implementation res ults pres ented in
OSMP
MOSA PART Tool is the MOSA
Program Ass essment and Rati ng
Tool to as sess the
implementation of MO SA
throughout acqui siti on life cyc le
Open Architecture
Rating
NOA OAAT
Process
DOD OAAT
Open arch itecture asses sment
resul ts presented in OSMP
OAAT is the Open Architeture
Assess ment Tool to asses s the
openess of the arc hitecture
implementation s olution
throughout acqui siti on life cyc le
DOD OSA,
Contract
GuideBook for
PM, V1.1, May
2013
System
Architecture
Design (SAD): TB
Components #2
and #3
Key Program
Element
PTB Product / Artifact
Resilient Program Technical Baseline Development Framework - Preliminary
SMC/DOD
Standard
PPT and Excel
Spread Sheet,
Popkin, Ra tional
Rose, etc
Process
Tool
Remark
Resilient PTB
Component
Proc. of SPIE Vol. 9469 946907-13
Downloaded From: http://proceedings.spiedigitallibrary.org/ on 05/26/2015 Terms of Use: http://spiedl.org/terms
Table 3. A Preliminary Check List for Government’s and Contractor’s Owned Resilient PTB Components
Techical Requireme nts: TRDs,
Interface Control Documents
√
InCDs may not be available at Pre-
Milsotone A
Work Breakdown Structure (WBS)
Work Product List (WPL) √Gov't Team needs to have the list
SEP / SEMP SEP SEMP Contractor Team owns SEMP
IS √
TEMP Program Level
STAR Program Level
DD Form 1494 Program Level √
APB √ N/A
Program Deliverable : CDRLs Program Level √
Rrequirement Baseline
Program Reviews and
Accomplishmen t Events
Program Level √
System Architecture Desi gn (SAD) DoDAF Views Gov't team owns OV's
OSA or MOSA Program Assessment
and Rating
√ At Program Level
Open Architecture Rating Program Level Gov't team may want to own this
Key Open Sub-S ystem (KOSS) √
Critical Technology Ele ment (CTE)
Sub-system Propri etary Interfaces
List to be Transitioned to Open
Interface
Program Level Gov't should must track this closely
Open System Management Plan
(OSMP)
Program Level
Integrated Master Plan (IMP) Program Level
Gov't team may want to own IMP at
program level
Estimate Task Duration
Integrated Mater Schedule (IMS) Program Level
Gov't team may want to own IMS at
program level
Critical Path Estimate √
Performance Measurement
Baseline (PMB)
√
Hardware (HW) Cost
Software (SW) Cost
IV&V cost
Manufacturing Cost
Maintenance cost
System Engiee ring Cost
Open System Approach (OSAP) Cost Program Level
Gov't team may want to own the
cost estimate to imple ment OSAP
at Program Level
R&D Cost
Disposal Cost
PM Cost Including Planning,
Managing, Excecuting, etc.
Life Cycle Cost (LCC) √
Total Ownership Cost (TOC) √
Requireme nts Risk √
KOSS Risk Program Level
Gov't team may want to own the
KOSS risk at Program Level
CTE Risk
System Design HW Risk
System Design SW Risk
Integration Risk √
Program Risks including Criti cal
Path, Cost, Schedule,
Manufacturing, Sustainment, etc
√
System
Architecture
Design (SAD):
TB Components
#2 and #3
√
Government/Contractor Owned Resilient PTB Check List - Preliminary
Remark
Key Program
Element
Resilient PTB Component
Government Owned
PTB Component
Contractor's Owned
PTB Component
Program
Requirement
(PRes): TB
Components #1
and #4
√
√
√
√
Program
Schedule (PS):
TB Component
#7, #8 and #9
Program Cost
(PC): TB
Component #6
Program Risk
(Pris): TB
Component #5
√
Proc. of SPIE Vol. 9469 946907-14
Downloaded From: http://proceedings.spiedigitallibrary.org/ on 05/26/2015 Terms of Use: http://spiedl.org/terms
achieve SMC’s vision on “Affordable” and “Resilient”, and presented an innovative SMC-OSAP that aligns the SMC’s
vision with the Four BBP 3.0 Initiatives (i)-(ii)-(iv)-(vi) for achieving “Program Resiliency”. Presently, this newly
innovative approach is being recommended to SMC for incorporation into future space system acquisition and sustainment
strategies. To make the proposed PFBF becomes Resilient, the paper has incorporated the newly recommended SMC-
OSAP into the PTBF through the integration with the current DAS/JCIDS/DODAF-IPM approach, which is referred to as
SMC-OSAP/DAS/JCIDS/DODAF-IPM approach for achieving Resilient PTBF.
It is anticipated that the proposed Resilient PTB components would meet the existing SMC’s vision and BBP 3.0
requirements, and be tracked throughout the life of a program. The need for a Resilient PTB tracking tool is inevitable,
and hence the recommended way-forward is to develop a tracking tool that can identify the required Resilient PTB
components at each milestone identified in the DAS and throughout the life of a program.
REFERENCES
[1] USAF, Report to Congressional Committees: Space Modernization Initiative (SMI) Strategy and Goals, April 2014.
[2] Honorable Frank Kendall, “Better Buying Power 3.0 - White Paper,” Office of the Under Secretary of Defense,
Acquisition, Technology and Logistics, 19 September 2014.
[3] U.S.A.F., “Better Buying Power 3.0 - Draft,” 10 December 2014
[4] Moshe Schwartz, “Defense Acquisitions: How DOD Acquires Weapon Systems and Recent Efforts to Reform the
Process,” May 23, 2014, Congressional Research Service, 7-5700, www.crs.gov, RL34026.
[5] DOD Instruction, “Operation of the Defense Acquisition System,” No. 5000.02, January 07, 2015.
[6] Lisa Guerra, Edited by Paul Graf, “Requirement Module: Configuration & Change Management, Space Systems
Engineering, Version 1.0, 2008.
[7] Mike Ucchino, “Developing and Maintaining the Technical Baseline,” AF Center for Systems Engineering, October
23, 2008, WPAFB, OH.
[8] Gary Hagan, “Overview of the DOD Systems Acquisition Process,” DARPA SBIR Phase I Training Workshop, April
2011, Defense Acquisition University.
[9] Defense Acquisition Guide Book, Defense Acquisition University, February 19, 2010, guidebook@dau.mil.
[10] Manual for the Operation of the Joint Capabilities Integration and Development System (JCIDS), JCIDS Manual,
January 19, 2012.
[11] Jennifer Owens, Jeff Belanger, Ray G. Bonesteele, Andy T. Guillen, and Rosie Duenas, “Defining Military Space
Capability Requirements for Successful Development,” Crosslink, The Aerospace Corp Magazine, Spring 2013.
[12] Air Force Space Command, Space and Missile Systems Center, Systems Engineering Requirements and Products
Standard, SMC Standard SMC-S-001, 1 July 2013.
[13] Glen T. Logan, “The Modular Open Systems Approach (MOSA) and The Its Impact on Systems Engineering
Revitalization,” Presented at Presented NDIA’s 44th Targets, UAVs and Range Operations Symposium Panama City,
FL, October 31st, 2006.
[14] DOD Modular Open Systems Approach (MOSA): http://www.acq.osd.mil/osjtf.
[15] MOSA Program Managers Guide, http://www.acq.osd.mil/osjtf/pmguide.html.
[16] Modular Open Systems Approach (MOSA) Continuous Learning (CL) Module, CLE 013, Defense Acquisition
University (DAU) us learning Modules: https://learn.dau.mil.
[17] Naval Open System Architecture, “KOSS Tool: KOSS Description and Application,” 5 August 2009, NAVAIR Public
Release, SPR-09-674.
[18] Mark Zimmerman, “US NOA and the OA Assessment Tool,” Lockheed Martin Mission Systems and Sensors.
[19] Naval OSA, “MOSA Program Assessment and Rating Tool (PART),” NAVAIR Public Release, SPR-09-674.
[20] DoDAF Architecture Framework Version 2.02, August 2010.
[21] Tien M. Nguyen, Andy T. Guillen, Sumner Matsunaga, “Building in Program Resiliency: Aligning SMC’s Vision on
Affordable and Resilient Acquisition and Sustainment with BBP 3.0,” SMC Resiliency Workshop, March 11, 2015,
Aerospace Report No. TOR-2015-01574.
[22] DoD DAG Chapter 4 – Systems Engineering, 15 May 2013.
ACKNOWLEDGEMENT
The authors would like to express their appreciation to Mr. Jeff Belanger, Ms. Jenifer Owens, Dr. Inki A. Min, Mr. Samuel
Lim, Dr. Charles Schwartz, Mr. Brian Shaw, Dr. Amy Weir and Dr. Christopher Tsan of The Aerospace Corporation, and
Mr. Mark Hedgepeth of SMC for their constructive comments, inputs and valuable suggestions.
Proc. of SPIE Vol. 9469 946907-15
Downloaded From: http://proceedings.spiedigitallibrary.org/ on 05/26/2015 Terms of Use: http://spiedl.org/terms
