國防科技專案管理(Iii)

02/22/1602/22/16 國防工業發展協會國防工業發展協會 11
國防科技專案管理國防科技專案管理
-- 政府與企業體籌獲之需求規劃與專案管理政府與企業體籌獲之需求規劃與專案管理
國防工業發展協會國防工業發展協會
科技顧問科技顧問
(2007(2007 年年 77 月月 ))
尹守紀尹守紀
E-mail:alexsj.yin@msa.hinet.net

02/22/16 國防工業發展協會 2
目錄：目錄：
1.1. 國防科技系統發展之現況與趨勢國防科技系統發展之現況與趨勢
2.2. ITIT 專案之成功與失敗統計資料專案之成功與失敗統計資料
3.3. 政府與企業體所面對之共同趨勢政府與企業體所面對之共同趨勢
4.4. 「麥肯錫問題解決模型「麥肯錫問題解決模型
5.5. 國防科技有關需求規劃之改進國防科技有關需求規劃之改進
a)a) 「需求「需求 (Requirements)(Requirements) 」」
b)b) 「籌獲「籌獲 (Acquisition)(Acquisition) 」」
c)c) 「規畫、計畫、預算與執行制度「規畫、計畫、預算與執行制度 (Planning,(Planning,
Programming, Budgeting & Executing SystemProgramming, Budgeting & Executing System ，，
PPBEPPBE ）」）」

1.1 - 20072007 年對遠征戰鬥載具年對遠征戰鬥載具 (EFV, Expeditionary(EFV, Expeditionary
Fighting Vehicle)Fighting Vehicle) 之檢討：之檢討： “ 4.5 小時就故障美兩棲戰車玩完”
費時十年，耗資十七億美元（約台幣五百六十億元）研發費時十年，耗資十七億美元（約台幣五百六十億元）研發
的美國陸戰隊兩棲戰鬥車平均四個半小時故障一次，的美國陸戰隊兩棲戰鬥車平均四個半小時故障一次，軟體軟體
設計不良設計不良，液壓系統還會溢漏，有時甚至自動轉向。，液壓系統還會溢漏，有時甚至自動轉向。

1.2 -1.2 - 2007 年對 JSF 之檢討：“有改善但仍須加強改
進”
GAO-07-360 (15 March 2007)GAO-07-360 (15 March 2007) ：： JOINT STRIKE FIGHTER- Progress Made and Challenges RemainJOINT STRIKE FIGHTER- Progress Made and Challenges Remain
根據美國政府的一份報告顯示，將作為美軍以及盟國空軍新一代攻擊機之用的根據美國政府的一份報告顯示，將作為美軍以及盟國空軍新一代攻擊機之用的 F-35F-35 閃電二型閃電二型 (Lightning II)(Lightning II) 聯合打聯合打
擊戰機擊戰機 (JSF, Joint Striker Fighter)(JSF, Joint Striker Fighter) ，每架成本已上漲，每架成本已上漲 20%20% ，目前的單價達，目前的單價達 82108210 萬美元。萬美元。
美國國會稽核處美國國會稽核處 (GAO, General Accounting Office)(GAO, General Accounting Office) 在報告中也指出，美國國防部擬到在報告中也指出，美國國防部擬到 20272027 年總計購入年總計購入 24002400 架架
JSFJSF 的進度也完全落後，但的進度也完全落後，但 GAOGAO 仍認為，仍認為，發展與採購速度應減緩，避免倉促進行飛行測試和其他發展計畫發展與採購速度應減緩，避免倉促進行飛行測試和其他發展計畫。。
GAOGAO 表示：「整個表示：「整個 JSF(JSF( 到到 20272027 年年 )) 的的武獲武獲成本，成本，已增加已增加 316316 億美元億美元」，也就是每架飛機較」，也就是每架飛機較 20042004 年的成本估算年的成本估算成成
長長 12%12% 。。

The Design of the “Raptor”The Design of the “Raptor”
美國國防科技之代表作美國國防科技之代表作 F-22F-22
• 1981 年開始需求構想
• 籌獲單價 3.61 億美金 (181 架計 )
• 籌獲數量由 648 架降為 341 架再
降為 181 架
• 單機成本增加 188.7% (181 架計
)
• GAO 將 F-22 列為非成功計畫
• 2006/06 F-22 戰機與美國 F-
15 、 F-16 和 F-18 現役主力
戰機進行了模擬空戰，並取得
了 0 比 144 的完勝戰績

Lockheed's Flying DudLockheed's Flying Dud
-The Self-Locking F-22-The Self-Locking F-22
April 10, 2006April 10, 2006 一架一架 F-22F-22
座艙發生鎖死無法開，啟座艙發生鎖死無法開，啟 55
個小時後由消防隊以電鋸切個小時後由消防隊以電鋸切
割割 3/4 inch3/4 inch 厚座艙罩厚座艙罩；；總總
計損失計損失 $1.28 million$1.28 million ，，
其中座艙罩為其中座艙罩為
$286,000,$286,000, ，機身重新噴，機身重新噴
塗材料為塗材料為 $1 million$1 million
發生原因主要為軟體缺陷所發生原因主要為軟體缺陷所
造成造成
F-22F-22 軟體程式碼大約有軟體程式碼大約有
2M SLOC2M SLOC

1.3 -1.3 - 20062006 年年 GAOGAO 對對 66 項合約成效之檢討項合約成效之檢討
 檢討結論：預算超支、時程落後
承約商
CMM/
CMMI
Lockheed Martin
Tactical Aircraft
System
SW-CMM ： L4
1999
Boeing Integrated
Defense Systems
CMMI-
SE/SW/IPPD/S
S ： L5 2004
Lockheed Martin
Aeronautics Company/
Boeing Integrated Defense
Systems
SW-CMM ： L4
1997
CMMI-
SE/SW/IPPD/SS ：
L5 2004Lockheed Martin
Aeronautics Company/
Boeing Integrated Defense
Systems
SW-CMM ： L4
1997
CMMI-
SE/SW/IPPD/SS ：
L5 2004Lockheed Martin
Missiles and Space
Systems
CMMI-
SE/SW/IPPD/S
S ： L3 2005
General Dynamics
Land Systems
CMMI-SW ： L5
(2002)

02/22/16 國防工業發展協會 Slide 8
FY03 Defense Authorization Act
Section 804
• Requires Services and applicable Agencies establish “software acquisition
process improvement programs” within 120 days (March 2003)
• Army, Navy, Air Force
• MDA, DISA, DLA, DFAS, and Health Affairs
• Requires ASD(NII) and USD(AT&L) to…
• Prescribe uniformly applicable guidance
• Ensure compliance by Service/Agency Components
• Section 804 approach to Component implementation identified eight process
improvement areas:
1) Acquisition Planning
2) Requirements Development and Management
3) Configuration management
4) Risk Management
5) Project Management and Oversight
6) Test and Evaluation
7) Integrated Team Management
8) Solicitation and Source Selection
• Past performance, Process maturity, Product maturity
2003.03,2
1 揭示採購
單位必須改
善之 8 項領
域
： Section 804 要求領域
：美國國防部另增領域

KSLOC
F/A-18C/D SMUG/
RUG 14268K
F/A-18E/F
17101K
F/A-18C/D XN-8
6629K
F/A-18 Night Attack
3054k
F/A-18C/D 2130K F-14D
416K F-14B 2866K
A-7E
16K
F-14 80K
A-4 (ARBS) 16K
A-6E 64K
F/A-18A/B 943K
F-14B 364K
AV-8B Night
Attack 1780K
AV-8B Radar 3748K
AH-1 NTS 1000KAH-1 764K
A-E SWIP 364KAV-8B 764K
0
3000
6000
9000
12000
15000
18000
66 70 74 78 82 86 90 94 98 02
Aircraft IOC, Year
EA-6B ICAP2
BLK 89 2203K
E-A6B ICAP1
48K
EA-6B ICAP2
BLK 82 395K
EA-6B ICAP2
BLK 86 779K
06 10
•JSF
•UAVs
•NCW
•Inter-System
Operability
1.4 -1.4 - 現代武器系統所面對之趨勢趨勢 (1) ：系統軟體
複雜性遽增 (Increasing System Complexity)
造成預算超支、時程落後
原因之為軟體複雜性劇ㄧ
增
複雜性為『人月神話』所
歸類於固有性軟體問題

1.5 -1.5 - 現代武器系統所面對之趨勢現代武器系統所面對之趨勢 (2)(2) ：：軟體比重
遽增 (Functionality Provided by Software in DoD Systems is Increasing)
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
1960 1964 1970 1975 1982 1990 2000
%offunctionalitySWprovides
Ref: Defense Systems Management College
F-4 A-7
F-111
F-15
F-16
B-2
F-22
造成預算超支、時程落後原因之
二為軟體比重遽增
如人月神話之“ No silver
bullets” 所敘述將因為 Project
Team 的溝通問題導致 Cost
overruns and schedule delay

Special
Ops
Intel
Center
JCS
En-Route
C2
Global
Grid
Enroute Mission Planning
and Retargeting
AF OSC
Tanker/
Airlift
Node
Space
Node
Distributed Ops
AF OSC
Distributed Ops
CAOC
Sensor-to-Decision
Maker-to-Shooter
Sensor-to-Shooter
EO
C
JFACC
Afloat
Collaborative
tools
Need for Interoperability of Real-time Assets in the Global Grid
1.6 -1.6 - 現代武器系統所面對之現代武器系統所面對之趨勢趨勢 (3)(3) ：：系統介
面複雜性遽增 (Interoperability)

2.1 - ITIT 專案之成功與失敗統計資料專案之成功與失敗統計資料
16
27
26
28
34
29
35
31
40
28
23
15
18
19
53
33
46
49
51
53
46
0 20 40 60 80 100
1994
1996
1998
2000
2002
2004
2006
Successful
Failed
Out of Time/Budget
Chaos Report:1994
Chaos Report from
1994 to 2006

2.22.2 -- 『『 The CHAOS Report (1994)The CHAOS Report (1994) 』』所公佈所公佈
的專案失敗的專案失敗 1010 大主因大主因
Project Impaired FactorsProject Impaired Factors % of Responses% of Responses
1. 需求不完整 Incomplete Requirements (SE) 13.1%13.1%
2. 使用者參與不足 Lack of User Involvement (SE,
PM)
12.4%12.4%
3. 資源不足 Lack of Resources (PM) 10.6%10.6%
4. 不實際之估算 Unrealistic Expectations (SE, PM) 9.9%9.9%
5. 行政支援不足 Lack of Executive Support (SE,
PM)
9.3%9.3%
6. 需求與規格之變更 Changing Requirements &
Specifications (SE, PM, CM)
8.7%8.7%
7. 規劃不周全 Lack of Planning (PM) 8.1%8.1%
8. 產品過時 Didn't Need It Any Longer (SE) 7.5%7.5%
9. IT 管理資源不足 Lack of IT Management (PM) 6.2%6.2%
10. 技術不成熟 Technology Illiteracy (SE, PM) 4.3%4.3%
OtherOther 9.9%9.9%

『『 The CHAOS Report (1994)The CHAOS Report (1994) 』』所公佈所公佈
的專案成功的專案成功 1010 大主因大主因
Project Success FactorsProject Success Factors % of Responses% of Responses
1. 邀請使用者參與 User Involvement 15.9%15.9%
2. 完善之行政支援 Executive Management Support 13.9%13.9%
3. 需求完整 Clear Statement of Requirements 13.0%13.0%
4. 規劃周全 Proper Planning 9.6%9.6%
5. 實際之估算 Realistic Expectations 8.2%8.2%
6. 較密集之專案里程碑 Smaller Project Milestones 7.7%7.7%
7. 稱職的工作人員 Competent Staff 7.2%7.2%
8. 自有掌控權 Ownership 5.3%5.3%
9. 明確之目標 Clear Vision & Objectives 2.9%2.9%
10. 工作努力且專心的工作人員 Hard-Working,
Focused Staff
2.4%2.4%
OtherOther 13.9%13.9%

不良不良 RequirementsRequirements 對於專案對於專案 BugsBugs 與與 CostCost 之影響之影響
Software Bugs
Percentage of Bugs by Source Percentage of Cost of Fixing
Bugs by Source
8 2
13
56
27
7
10 Requirements
Design
Code
Other
Poor Requirements 或
不將 Requirements 當
一回事將引致〝焦油坑
〞

不良不良 RequirementsRequirements 對於專案矯正成本之影響對於專案矯正成本之影響
Requirements
Design
Code Test
Test
Code
Design
Requirements
0
5
10
15
20
25
30
35
40
45
50
Relative Cost
to Fix
Phase Found
Defect
Type
Relative Cost to Fix Defects per Phase Found
Test Code Design Requirements
Requirement 階段的
Defect 最高需 50 倍
的支出予以矯正，若
能在 design phase 矯
正，可降為 5 倍
5
10
50

19751975 年於『人月神話』所揭示之軟體問題年於『人月神話』所揭示之軟體問題
Frederick P. Brooks Jr.Frederick P. Brooks Jr.
• IBM OS/360 Project Manager
(1964-1965)
• Introduced in 1963 but not
completed until 1968
• 5000 man-years of effort at
IBM
““No Silver Bullet”No Silver Bullet” 　　
Published on 1986Published on 1986 ：：
軟體問題而引出本質性
（ essence ）與附屬性
（ accident ）工作的分類
Essence and Accident in
Software Engineering
No single development in
either technology or in
management technique
promises even one order of
magnitude of improvement in
productivity, reliability or
simplicity
Hard part of building software
is the specification, design
and testing of the conceptual
constructs for a system
(essential), not the labor of
representing it (accidental)

3.1 -3.1 - 政府與企業體所面對之共同趨勢政府與企業體所面對之共同趨勢
由於開放式架構（由於開放式架構（ Open System ArchitectureOpen System Architecture ）、服務導向架構）、服務導向架構
（（ Service Oriented ArchitectureService Oriented Architecture ，， SOASOA ）等，致使專案於）等，致使專案於 RFPRFP
時尚難以明確浮現需求時尚難以明確浮現需求
系統介面複雜性遽增 (Interoperability) ：由 System 進化為
System of Systems ( 群組系統群組系統 ))
軟體比重遽增 Functionality Provided by Software in DoD
Systems is Increasing ：進化為『軟體建構功能之群組系統『軟體建構功能之群組系統
(SOSIS)(SOSIS) 』』
系統結構複雜性遽增 (Increasing System Complexity) ：由單一架
構進化為架構框架 (Architecture Framework ，諸如
DODAF 、 FEAF 、 TEAF 、 TOGAF 、… .)
共同目標共同目標：：
1.1. 如何導出“完整的需求”如何導出“完整的需求”
2.2. 如何在時程與預算之目標下達成需求如何在時程與預算之目標下達成需求

3.2 - 新一代武器系統需求概念與視觀（ Viewpoints ）結
構：『軟體建構功能之群組系統 (SOSIS) 』與『架構框架
(Architecture Framework) 』
From System to SoftwareFrom System to Software
Intensive System of SystemsIntensive System of Systems
(SISOS)(SISOS)
From Framework toFrom Framework to
Architecture FrameworkArchitecture Framework
(AF)(AF)
JOA
Operational
Systems
Technica
l
Standard
1999 + Standard
1998
Node
A
Node
B
Node
C
IER
CADM
DDDS
DDDS
LISI
LISI
TRM
SHADE
JTA
COE
UJTL
COE
LISI
CADM
System
X
System
Y
System
X
System
Z
System
X
Node
A
Node
B
Node
C
System
Y
System
Y
IER
IER
Activity 1
Activity 2
Activity 3
Activity 1
Activity 2
C2
Model
Sensor
Model
Combat
Model
Integration
Communications
Model

20Chesapeake Chapter INCOSE OOSEM WG
OOSEM RUP Bridged ZF
Object OrientedStructured Analysis (Functional)
Functional Object OrientedDiagrams
Modeling
Methods
FE AF Zachman FW
Architecture Framework
C4ISR/DoD AFArchitecture
Frameworks
AF 已是政府與企業體的共同語言
(Architecture Framework Relationships)
e.g., IDEF0 e.g., OMG UML
SD SA Other
Standards
未限定於使用
Functional Diagram
或 UML Diagram

4.14.1 麥肯錫問題解決模型麥肯錫問題解決模型
由「麥肯錫問題解決模型」探索美國聯邦由「麥肯錫問題解決模型」探索美國聯邦
政府採購之需求規畫與專案管理政府採購之需求規畫與專案管理
麥肯錫問題解決模型：該模型分麥肯錫問題解決模型：該模型分
成六部份，其中核心三角形部分成六部份，其中核心三角形部分
為麥肯錫公司內部所進行的問題為麥肯錫公司內部所進行的問題
解決程序，外面三部分乃是與客解決程序，外面三部分乃是與客
戶進行企業需求了解（戶進行企業需求了解（ BusinessBusiness
NeedNeed ）、需要企業主領導統御配）、需要企業主領導統御配
合（合（ LeadershipLeadership ）與實際應用到）與實際應用到
企業程序（企業程序（ ImplementationImplementation ））
找出解決問題（找出解決問題（ ProblemsProblems ）所）所
需要（需要（ NeedsNeeds ）的為企業尋求創）的為企業尋求創
新（新（ InnovationInnovation ）之根源）之根源
分析問題
• 界定問題
• 設計分析作業
• 蒐集資料
• 解讀分析結果
發表成果
• 條理分明
• 說服聽眾
直覺
資料
管理組織
• 團隊：組成 . 誘導 . 發展
• 客戶：積極參與
• 自己：生活事業間保持平衡

Informatio
n Need
Problem
Intuition
Data
Analyzing Information
•Framing – Hypothesize –Issue Trees
•Designing – Outline – Work Plan
•Gathering Data – Facts – Interviews
•Interpreting – Analyzing - Evaluating
Solution
Final Presentation
•Be Structured
•Keep it Simple
•Tailor to Audience
Managing
•Team
•Self
•Time
McKinseyMcKinsey
StrategicStrategic
ModelModel
Adapted from The McKinsey Mind, Rasiel p xv

4.2 -4.2 - 麥肯錫麥肯錫 MECEMECE 原則與專案管理原則與專案管理 WBSWBS 技巧技巧
在專案管理中（在專案管理中（ ProjectProject
Management, PMManagement, PM ），）， MECEMECE
原則也廣泛運用，其中最常聽原則也廣泛運用，其中最常聽
到的專案管理原則與技巧為到的專案管理原則與技巧為
WBSWBS 。所謂的。所謂的 WBSWBS 即是即是
Work Breakdown StructureWork Breakdown Structure
（工作分解結構）的縮寫，根（工作分解結構）的縮寫，根
據據 WikipediaWikipedia 說明，說明， WBSWBS 為為
專案管理基本技巧之一，專案管理基本技巧之一， WBSWBS
使用階層樹狀結構使用階層樹狀結構
（（ Hierarchical TreeHierarchical Tree
StructureStructure ）與）與 100%100% 原則原則
（（ 100% Rule100% Rule ）來定義與組織）來定義與組織
專案範圍（專案範圍（ Project ScopeProject Scope ）。）。
此外，一個優良的專案此外，一個優良的專案 WBSWBS
技巧，是針對產出技巧，是針對產出
（（ OutcomesOutcomes ）所進行的拆解）所進行的拆解
，而非工作項目（，而非工作項目（ ActionsActions ））
拆解。拆解。 (( 科技產業資訊室科技產業資訊室 ----
AmberAmber 編撰編撰 ))
MECE ：麥肯錫 MECE 原則 ( （ Mutually
Exclusive, Collectively Exhaustive ）
WBS: 工作分解結構 (Work Breakdown
Structure)

5.5. 國防科技有關需求規劃之變革國防科技有關需求規劃之變革
1.1. 1961-20031961-2003 ：以“需求導向”結合規劃、計劃、預算三項：以“需求導向”結合規劃、計劃、預算三項
管理體系（管理體系（ PPBSPPBS ））
2.2. 20032003 ：以“能力導向”結合規劃、計劃、預算三項管理體：以“能力導向”結合規劃、計劃、預算三項管理體
系，並加上度量分析之執行監控（系，並加上度量分析之執行監控（ PPBEPPBE ））
3.3. 以“聯合作戰能力整合與發展系，统以“聯合作戰能力整合與發展系，统 JCIDS”JCIDS” 取代“需求取代“需求
生成系統，生成系統， RGS”RGS” ，以作戰能力需求取代傳統威脅分析，以作戰能力需求取代傳統威脅分析
4.4. 籌獲政策之變革：籌獲政策之變革：
a.a. 採用“漸進式採購（採用“漸進式採購（ Evolutionary AcquisitionEvolutionary Acquisition ，， EAEA ）” 策略）” 策略
，確定技術成熟之後再轉為作戰能力，確定技術成熟之後再轉為作戰能力
b.b. 採用“螺旋式發展（採用“螺旋式發展（ Spiral DevelopmentSpiral Development ，， SDSD ）”策略，確定）”策略，確定
需求明確之後再轉入發展階段需求明確之後再轉入發展階段
c.c. 採用“績效服務採購（採用“績效服務採購（ Performance Based ServicePerformance Based Service
AcquisitionAcquisition ，， PBSAPBSA ）”以適用於聯合作戰能力的需求）”以適用於聯合作戰能力的需求
d.d. 選用“性能導向後勤（選用“性能導向後勤（ Performance Based LogisticPerformance Based Logistic ，， PBLPBL ））
”策略，少後勤負担减”策略，少後勤負担减
e.e. 採用“基於模擬的採購（採用“基於模擬的採購（ Simulation Based AcquisitionSimulation Based Acquisition ，，
SBASBA ）” ，以謀擬仿真技術推演未來之可能性威脅以達到風險）” ，以謀擬仿真技術推演未來之可能性威脅以達到風險
管理目標管理目標

需求規劃需求規劃
由企業體之策
略目標訂定
未來發展能力
之需求
以聯合需求評
估未來發展能
力需求之落差
由落差之清單
排定優先順序
Capabilities
Needs
擬定需求文件
Requirements
Documentation

『『從國防管理革命看頂層設計從國防管理革命看頂層設計』』
李炳彥李炳彥 20062006 年年 0505 月月 3030 日日
19611961 年，福特汽車公司總裁麥克納馬拉出任美國國防部長。他帶著年，福特汽車公司總裁麥克納馬拉出任美國國防部長。他帶著
企業管理的成功經驗——成本效益分析和系統管理方法，對僵化低效企業管理的成功經驗——成本效益分析和系統管理方法，對僵化低效
的國防部進行全面改組，建立起的國防部進行全面改組，建立起“規劃、計劃與預算”（“規劃、計劃與預算”（ PPBSPPBS ））制度制度
，用來對國防資源進行綜合管理，並據此編制武器裝備採購計劃和國，用來對國防資源進行綜合管理，並據此編制武器裝備採購計劃和國
防預算，從而使美國的國防管理跨進了現代科學管理的新階段。防預算，從而使美國的國防管理跨進了現代科學管理的新階段。
2020 世紀世紀 9090 年代，克林頓政府的國防部長科恩提出：“要在國防部掀年代，克林頓政府的國防部長科恩提出：“要在國防部掀
起一場商務革命，把曾經使美國公司恢復其市場主導地位的管理技術起一場商務革命，把曾經使美國公司恢復其市場主導地位的管理技術
與業務方式引入國防部。”在美軍的新軍事變革前期，主要是強化“與業務方式引入國防部。”在美軍的新軍事變革前期，主要是強化“需需
求導引求導引”的軍事採購革命。”的軍事採購革命。
20032003 年年 55 月，拉姆斯菲爾德在推進美軍新軍事變革中，發布“重大倡月，拉姆斯菲爾德在推進美軍新軍事變革中，發布“重大倡
議決定議決定 913”913” 文件，宣布對麥克納馬拉的“文件，宣布對麥克納馬拉的“ PPBS”PPBS” 進行重大改革，以“進行重大改革，以“
規劃、計劃、預算與執行”（規劃、計劃、預算與執行”（ PPBEPPBE ）代之，做為國防資源分配管理）代之，做為國防資源分配管理
的新辦法、新制度。的新辦法、新制度。
““PPBS”PPBS” 由規劃、計劃、預算三個階段組成。由規劃、計劃、預算三個階段組成。
規劃階段主要是確定長期戰略規劃，根據美國規劃階段主要是確定長期戰略規劃，根據美國 55 －－ 2020 年所面臨的年所面臨的威威
脅脅，提出應具備的軍事力量。，提出應具備的軍事力量。

『『從國防管理革命看頂層設計從國防管理革命看頂層設計』』
李炳彥李炳彥 20062006 年年 0505 月月 3030 日日
在計劃階段，各軍種和國防部各業務局根據規劃文件以及國防資源的在計劃階段，各軍種和國防部各業務局根據規劃文件以及國防資源的
限制情況，制定相應的武器裝備發展計劃，確定優先發展的項目。限制情況，制定相應的武器裝備發展計劃，確定優先發展的項目。
在預算階段，主要是依據所確定的計劃項目，編制經費預算。在預算階段，主要是依據所確定的計劃項目，編制經費預算。
就麥克納馬拉對國防管理的整體改革來說，雖然引入了系統工程方法就麥克納馬拉對國防管理的整體改革來說，雖然引入了系統工程方法
，但還未能從，但還未能從系統哲學、復雜性科學系統哲學、復雜性科學的層面看問題，致使改革存有很的層面看問題，致使改革存有很
多缺陷。比如：把企業價觀與軍人價觀等同起來，用比例尺代替值值多缺陷。比如：把企業價觀與軍人價觀等同起來，用比例尺代替值值
了指揮藝術等。這些缺陷，在后來的戰爭實踐中受到批判。不過，美了指揮藝術等。這些缺陷，在后來的戰爭實踐中受到批判。不過，美
軍由此在國防管理中所實行的“軍由此在國防管理中所實行的“ PPBS”PPBS” 制度，統籌國防資源，對裝備制度，統籌國防資源，對裝備
建設實行全系統、全壽命、全效益管理，較好地把建設實行全系統、全壽命、全效益管理，較好地把長遠規劃、中期計長遠規劃、中期計
劃和近期安排結合起來劃和近期安排結合起來，則是科學的、合理的，並在實踐中收到了良，則是科學的、合理的，並在實踐中收到了良
好效果。好效果。
PPBEPPBE 制度確立了“基於能力”的採購思想，更加注重規劃、計劃與軍制度確立了“基於能力”的採購思想，更加注重規劃、計劃與軍
事能力需求的結合。事能力需求的結合。
““ 基於能力”的採購思想的實質，是強調明確基於能力”的採購思想的實質，是強調明確未來敵人將可能如何作戰未來敵人將可能如何作戰
，比明確誰是敵人、戰爭將在裡發生更重要哪，比明確誰是敵人、戰爭將在裡發生更重要哪愈是發展先進技術，愈﹔愈是發展先進技術，愈﹔
要強調作戰需求的牽引作用。要強調作戰需求的牽引作用。
因此，因此， PPBEPPBE 制度的規劃階段，主要任務是確定制度的規劃階段，主要任務是確定作戰能力需求作戰能力需求，為下，為下
一步的計劃階段確定國防政策和戰略指導方針。一步的計劃階段確定國防政策和戰略指導方針。

需求規劃改變建軍思維需求規劃改變建軍思維
JR
Systems
Capabilities
Based?
Interoperability?
Impact on:
Training?
Doctrine?
Leadership?
Facilities?
QDR,
DPG,
CPG
• Phase I, II, III BDA
• MEA
• Target nominations
• Special Studies
• Maritime CTL
• Phase I, II BDA
• Propose targets
• Track JFLCC Targets
• Phase I, II BDA
• MEA
• Target study
• Point mensuration
• No strike lists
• Target materials
• Phase I, II, III BDA
• Phase II BDA;
Combat Assessment
• CDL, JNFL, Pre-
planned JTL
• Target materials
• Target nomination
• Phase I, II BDA; MEA
• Tgt. Folders;weaponeering
• ATO, JTl
JFC
(JOC/JIC)
JFLCC
(ACE)
WOCMAW
JFMCC
F2C2
DCCC
DIA
NMJIC
JFSOCC
JFACC
(AOC)
• Phase I BDA
• Phase I BDA
• Coalition Coordination
Caveats:
• Extract from
USCENTCOM
Objective Architecture
Concerning Targeting –
November 1997 Draft
• Nodes; info. exchanges;
functions shown do not
represent a complete set
MIDB
Changes
Target
Nominations
BDA Reports
(imagery/text)
• BDA Reports
(imagery/text)
• Collection
Requirements
• BDA Reports
(imagery/text)
• Target materials/analysis
• BDA Reports (imagery/text)
Collection
Requirements
• Weapon System Video
• MISREPs
• Combat Reports
• Munitions Effects
• Target material requests
• Target materials/analysis
• Enemy Force
Effectiveness
• Collection
Requirements
• Target
Nominations • BDA Reports
(imagery/text)
• Weapon System Video
• MISREPs
• Combat Reports
• Munitions Effects
• Target material requests
• Collection Requirements
A1 A2 A3
A1.2 A3.1 A3.2A1.1
A3.2.1 A3.2.2
A0
Activity
Hierarchy
Activity
Diagram
A1
A2
A3
EVENTS/TIME
NODES
NODE 1 NODE 2 NODE 3
EVENT 1
EVENT 2
EVENT 3
EVENT 4 EVENT 5
EVENT 6
EVENT 7 EVENT 8
time 1
time 2
time 3
time 3'
{formula relating
time 3 to time 3'}
time n
{formula relating
time 1 to time 2}
SATCOM Interface
NODE A
NODE B
NODE C
SYSTEM
2
SYSTEM
1
SYSTEM
1
SYSTEM
3
SYSTEM
4
EXTERNAL
CONNECTION
SYSTEM
1
COMMS Interface
COM
M
S
In
terface
SYSTEM
2
COMMS Interface
One-way SATCOM Interface
F/A-18A/BF/A-18A/B
Navy
Tankers4
E-2CE-2C
F-14DF-14D
F-14A, BF-14A, B
Tactical Surveil
P-3C S-3B
SH-60 UAVs
etc.
Tactical Surveil
P-3C S-3B
SH-60 UAVs
etc.
EA-6BEA-6B
ARC
C2WC3
ASUWC
ASWC
F/A-18
C/D, E/F
JFACCJFACCJFMCCJFMCC
JFLCC JFSOCCJFSOCCNATO Allies
Coalition Allies
JFC
JOCJIC
JFC
JOCJIC
CWCCWC ACAACAAADCAADC
SWC
A
JM
AJM
AJM
AJM
A
JM
A
JM
AJM
AJM
AJM
A
JM
Joint Elements
National Theater
DSP SOF
OTHR HFDF
ASW Arrays
FOSICs/FOSIFs
etc
E-31 U-2R
RC-
135V2 EP-3
ES-3A
UAVs
Tankers 4
Ships 6
Subs6 etc
Joint Elements
National Theater
DSP SOF
OTHR HFDF
ASW Arrays
FOSICs/FOSIFs
etc
E-31 U-2R
RC-
135V2 EP-3
ES-3A
UAVs
Tankers 4
Ships 6
Subs6 etc
AAWC
AEGIS Cruiser: CG-47 Class
*(Alternate, CV)
CIC
AAWC
AEGIS Cruiser: CG-47 Class
*(Alternate, CV)
CIC
A J M
A
C
J N M
R
A
JN
M
Z
A
JN
M
Z
AJNMZ
A
JN
M
Z
AM
AJNMZ
A C J M Z
C J
A C M
C
C J
A JN M Z
A J N M Z
A JN M Z
A JN M Z
A
C
J N
M
A C
JM Z
A JN M Z
C
M
A J M
A
C
J N M
R
A
JN
M
Z
A
J N
M
Z
AJNMZ
A
JN
M
Z
AM
AJNMZ
A C J M Z
C J
A C M
C
C J
A JN M Z
A J N M Z
A JN M Z
A JN M Z
A
C
J N
M
A C
JM Z
A JN M Z
C
M
USAF
Control
E-31 CRC
CRE
Weapons
F-15 F-16
Force
AOC
USAF
Control
E-31 CRC
CRE
Weapons
F-15 F-16
Force
AOC
Control
E-31 CRC
CRE
Weapons
F-15 F-16
Force
AOC
AEGIS
Destroyers
DDG-51
AEGIS
Cruisers
CG-47
Aircraft
Carriers
CV
Other AAW
Ships
CGN-36/38, DDG-99 3
Other AAW
Ships
FFG-7
Other
Ships
AEGIS
Destroyers
DDG-51
AEGIS
Cruisers
CG-47
Aircraft
Carriers
CV
Other AAW
Ships
CGN-36/38, DDG-99 3
Other AAW
Ships
FFG-7
Other
Ships
Force
AAMDC FPTOC
Control Weapons
Army
Force
AAMDC FPTOC
Control WeaponsForce
AAMDC FPTOC
Control Weapons
Army
USMC
Force
TACC
Control
TAOC / SAAWC /
EWC
Weapons
F/A-18
AV-8B
HAWK TMDD
USMC
Force
TACC
Control
TAOC / SAAWC /
EWC
Weapons
F/A-18
AV-8B
HAWK TMDD
Near Term Operations as of 2003 -- Major Regional Conflict -- Theater Air and Missile Defense functions
Sources: Ref J6, J13, J62, J84, J94, J97, N3, N10, N11,N14, N16,N27,F1, B17, R8, R16, S11,S14-S24
Notesfor Navy Charts
1 AWACS 2 RIVET JOINT3 Formerly EWC 4 Aerial Refueling Aircraft 5May beindirect viaFleet gateway
6“Ships” & “Subs” refers to vessels ,w hichalthoughnot an integralpart of theJointForce, are tasked to provide surveillance
IntegratedIntegrated
ArchitecturesArchitectures
Systems
傳統之建軍架構傳統之建軍架構未來之建軍架構未來之建軍架構

Initial Capabilities Document (ICD)
FOR
JOINT HIGH SPEED INTRA-THEATER SURFACE LIFT
1. Joint Capability Area1. Joint Capability Area
2. Required Capability2. Required Capability
3. Concept of Operations3. Concept of Operations
SummarySummary
4. Capability Gap4. Capability Gap
5. Threat/Operational5. Threat/Operational
EnvironmentEnvironment
6. Functional Analysis Solutions6. Functional Analysis Solutions
SummarySummary
7. Final Materiel7. Final Materiel
RecommendationsRecommendations
Appendix A. IntegratedAppendix A. Integrated
Architecture ProductsArchitecture Products
Appendix B. Functional AreaAppendix B. Functional Area
Analysis, Functional NeedsAnalysis, Functional Needs
Analysis, and FunctionalAnalysis, and Functional
Solutions Analysis for JointSolutions Analysis for Joint
Intratheater High SpeedIntratheater High Speed
Surface LiftSurface Lift
Appendix C. ReferencesAppendix C. References
Appendix D. Acronym ListAppendix D. Acronym List
Appendix E. Universal Joint TaskAppendix E. Universal Joint Task
List (UJTL) – Strategic LevelList (UJTL) – Strategic Level
Theater Tasks andTheater Tasks and
Operational Level TasksOperational Level Tasks
Appendix F. High SpeedAppendix F. High Speed
Intratheater Surface ConnectorIntratheater Surface Connector
Lessons LearnedLessons Learned
Appendix G. U.S. Army TheaterAppendix G. U.S. Army Theater
Support Vessel ACTDSupport Vessel ACTD
Management PlanManagement Plan
Appendix H. U.S. Army TheaterAppendix H. U.S. Army Theater
Support Vessel AROC-approvedSupport Vessel AROC-approved
OperationalOperational
Requirements DocumentRequirements Document

past
Requirements Basis
( 需求生由產 Bottom up 演進為 Top down)
present
Systems
Requirements
Bottom up, stovepiped
Integrated at
Department
Systems
Requirements
Bottom up, stovepiped
Integrated at
Department
Joint Concept of Operations
Strategic
Direction
Joint Capabilities
Joint/Service Operating
Concepts

02/22/16 國防工業發展協會
31
Revolutionary
( 創新的 Top-down 架
構 )
Acquisition Decision Support Systems
In Transformation
( 需求必須整合戰略規劃藉由籌獲完成 )
Defense
Acquisition
System
聯合能力整合與發展系統
Joint Capabilities
Integration &
Development
System (JCIDS)
VCJCS/Service
Chief Oversight
Milestone Decision
Authority (MDA)
Oversight
Evolutionary
( 進展式籌獲而非一次
建置
的， Prototyping 、 FS
D 、 LRIP 、 FRP)
CJCS 3170.01C
24 June 03
MID 913 PPBS to PPBE
22 May 03
DoD 5000 Series
12 May 03 Revision
Emerging
( 新興的，依據
戰略指導訂定
兩年度的細部
預算與計畫規
劃作業 )
Planning,
Programming,
Budgeting & Execution
Process (PPBE)DEPSECDEF
Oversight

32
Operational
View
Operational
View
The
Operational View
describes and
interrelates the
operational elements,
tasks and activities, and
information flows required to
accomplish mission operations.
Technical
View
Technical
View
The
Technical View
describes the profile of rules,
standards, and conventions
governing systems implementation.
The
Systems View
describes and
interrelates the
existing or postulated
technologies, systems, and
other resources intended to
support the operational requirements.
Systems
View
Systems
View
由架構框架 (AF) 推導出滿足未來作戰能力 (Capability) 之框
架

33
UNCLASSIFIED
UNCLASSIFIED
JO TNI
S TA FFCHIE FS OF
Future Capabilities and Acquisition Process
Oversight
Requirements
Acquisition
D
O
T
M
L
P
F
Approved
ICD
MS A
Analysis
of
Capability
Solution
Sets
Demo
Demo Increment 1Increment 1
Demo
Demo
Demo
Demo
Increment 2Increment 2
Increment 3Increment 3
MS B
MS C
MS B MS C
MS B MS C
Refinement of
Solution Sets
CDD
CPD
Capability and Technology
Development
LRIP
LRIP
LRIP
FRP
SDD
JROC DAB
ICD - Initial Capabilities Document
CDD - Capabilities Development Document
CPD - Capabilities Production Document
JROC DAB
JROC DAB
FCBFCB
ProcessProcess
Functional Capability Board
(FCB) 執行 "capabilities
based assessment"

3402/22/16
 Engage moving targets at sea
 Large (100 ft), slow (15 knots)
 Weapon target discrimination
 Right threat target vs. neutral traffic
 Standoff outside threat rings
 Adverse weather
 Upgrades to current weapon systems:
 Joint Air-to-Surface Standoff Missile
 Sensor Fuzed Weapon (Wind Corrected
Munitions Dispenser Extended Range)
Capability: Destroy large slow-moving maritime targets
Long Range Strike...
Counter-MARITIME
Counter-
Maritime
ACTD ProductionPlans
NEAR TERM
WEAPON 08 09 10 11 12 13 14 150706
Funded Unfunded
Legend

3502/22/16
Capability: Destroy heavily defended, high
value, time sensitive targets located deep in
enemy territory
 Cruise Speed: Mach 3-5 > Mach 5
 Range: 400-600 NM 600-750 NM
 Time of Flight: <15 minutes <10 minutes
 Propulsion: Turbojet, Ramjet, DC Ramjet Scramjet
 Payload Wt: 300# (WDU-45B) 250-500#
 Guidance: GPS/INS, Network Centric, Seeker
Joint High Speed Weapon (JHSW) Hypersonic Missile
JHSW Navy TD/ SDD SDD/ProductionLab Tech Demos
Long Range Strike...
High Speed/Hypersonic Missile Concept
NEAR TERM
WEAPON 08 09 10 11 12 13 14 150706

36
Functional Area
Functional Concept
Integrated Architecture
Functional
Area
Analysis
D
O
T
M
L
P
F
Joint Capabilities Integration and
Development System -- CJCSI 3170
Independent
Analysis of
Materiel
Approaches
Materiel
Recommendation 1
Materiel
Recommendation 2
Overarching Policy --
NSS/NMS/Joint Vision
Joint Concept of Operations
Requirements/Acquisition IntegrationRequirements/Acquisition Integration
Functional Solution Analysisl l
Defense Acquisition System – DoD 5000
B CA
Initial
Capabilities
Document
CR TD SDD PD OS
Capability
Development
Document
Capability
Production
Document

02/22/1602/22/16 國防工業發展協會國防工業發展協會
CDSC-PM , 17 July 03 - 37
The Defense Acquisition ManagementThe Defense Acquisition Management
FrameworkFramework
BA
Concept
Refinement
System Development
& Demonstration
Production &
Deployment
Systems Acquisition
Operations &
Support
C
User Needs &
Technology Opportunities
Sustainment
FRP
Decision
Review
LRIP/IOT&E
Design
Readiness
Review
Technology
Development
(Program
Initiation)
Concept
Decision
Pre-Systems Acquisition
BA
Concept & Technology
Development
System Development
& Demonstration
Production &
Deployment
Systems Acquisition
Operations &
Support
C
User Needs &
Technology Opportunities
Sustainment
FRP
Decision
Review
LRIP/OT&E
Interim
Progress
Review
Pre-Systems Acquisition
Decision
Review
DoDI 5000.2, Oct 2000
DoDI 5000.2, May 2003
(Program
Initiation)

Operational Concept
System Functional Mapping
System Interface Mapping
OV-1
OV-4
OV-5
SV-3
SV-4
SV-5
OV-2
OV-3
SV-1 TV-1
SV-2 SV-6
Architecture Performance
and Behavior
OV-6C
SV-7
Executable
Model
CV-6CV-6 Capabilities Evolution DescriptionCapabilities Evolution Description
OV-1OV-1 High-level Operational Concept GraphicHigh-level Operational Concept Graphic
OV-2OV-2 Operational Node Connectivity DescriptionOperational Node Connectivity Description
OV-3OV-3 Operational Information Exchange MatrixOperational Information Exchange Matrix
OV-4OV-4 Command Relationships ChartCommand Relationships Chart
OV-5OV-5 Activity ModelActivity Model
OV-6COV-6C Operational Event/Trace DescriptionOperational Event/Trace Description
SV-1SV-1 System Interface DescriptionSystem Interface Description
SV-2SV-2 Systems Communication DescriptionSystems Communication Description
SV-3SV-3 Systems MatrixSystems Matrix
SV-4SV-4 System Functionality DescriptionSystem Functionality Description
SV-5SV-5 Operational Activity to System FunctionOperational Activity to System Function
Traceability MatrixTraceability Matrix
SV-6SV-6 System Information Exchange MatrixSystem Information Exchange Matrix
SV-7SV-7 System Performance Parameters MatrixSystem Performance Parameters Matrix
SV-8SV-8 System Evolution DescriptionSystem Evolution Description
SV-9SV-9 System Technology ForecastSystem Technology Forecast
SV-10SV-10 System Activity Sequence & TimingSystem Activity Sequence & Timing
TV-1TV-1 Technical Architecture ProfileTechnical Architecture Profile
TV-2TV-2 Standards Technology ForecastStandards Technology Forecast
The Role of Engineering and TechnologyThe Role of Engineering and Technology
Functional Architecture
Physical Architecture
1st Order Assessment:
Functionality
2nd Order Assessment:
Static Interoperability
3rd Order Assessment:
Dynamic Interoperability
OV-3
Note: There are dependencies between the Architecture
products that are not shown in the System
Engineering flow. Many of the products are
developed concurrently.
Architectures Provide the Framework and
Assessment for FoS/SoS Systems Engineering
Architectures Provide the Framework and
Assessment for FoS/SoS Systems Engineering
SV-8 TV-2
CV-6
Acquisition Plans
SV-9
SV-10
DRM
OPSITs
TTP
DRM: Design Reference Mission
OPSIT: Operational Situation
TTP: Tactics, Techniques, Procedures
Source: Mr. Steve Soules, Booz-Allen & Hamilton

Process
Outputs
Process
Inputs
Verification Loop
Design Loop
Requirements
Loop
Functional Analysis/
Allocation
DoD Architectural Framework Mapped into
the Systems Engineering Process
Requirements
Development
Design Synthesis
Systems Analysis,
Planning, Assessment,
and Control
(Balance and
Management)
OV/SV
SV/TV
OV
SV/TV
OV – Operational View
SV – Systems View
TV – Technical Standards View
1.AF 的 OV 、 SV 、 TV 等 products
將提供 system life cycle 之參用
2. Acquisition phase 將回歸到
System Engineering

Options for Roles and ResponsibilitiesOptions for Roles and Responsibilities
OptionOption
11
InitialInitial
CapabilitiesCapabilities
DocumentDocument
SystemSystem
SpecificationSpecification
StatementStatement
of Workof Work
Contract
Signed
22
InitialInitial
DocumentDocument
SystemSystem
SpecificationSpecification
StatementStatement
ofof
ObjectivesObjectives
Statement
of Work
Contract
Signed
33
InitialInitial
DocumentDocument
System
Specification
Statement
of Work
Contract
Signed
Government Developed Contractor Developed

Evolutionary Acquisition –
Incremental & Spiral Development
Evolutionary Acquisition –
Incremental & Spiral Development
Time
- Incremental
- Spiral
Warfighter
Capability
Known
increment
Known
increment
Known
increment
Known
increment
Partially
known
increment
Not known
increment
Not known
increment
==
First Fielded Capability
Technology Demos
Feedback from
warfighter

Time
Capability
Evolutionary Acquisition
Initial Operationally
Useful Capability
Technology Base
Requirements
Capability
Time
NO CAPABILITY
Capability
Single Step Approach
Technology Base
Requirements
CapabilityFOCIOC

性能導向後勤（ PBL ）
NGSS PBL Goals
• Increase reliability, maintainability, and supportability
• Influencing early design
• Focusing on system design for operational effectiveness
• Provide an interdisciplinary engineering management process
• Evolves and verifies an integrated life cycle balance set of system solutions
• Produces customer satisfaction
• Develop a total system design solution that balances
• Cost
• Schedule
• Performance
• Risk.
• Provide a system that can be produced economically and supported through the life
cycle.
• Open Systems Approach tp maximize internal and external interface capability of
the systems/ subsystems using open system approach.

44
基於模的擬採購 (SBA: What
Is It?)
• SBA comes to life in a robust M&S
engineering environment
• SBA supports a revised acquisition process
• SBA involves significant cultural change
CG47
DD963
DDG51
CG47
DD963
DDG51
PLAT
SIG/KINE
C
2
COMMS
DATAFUSION
SENS1
SENS 2
SENS 3
SENS 4
Conceptual Development
Functional Design
MNS
ORD
SYSTEM
CONCEPTS
Top Level System
Requirements
Physical & Info
System (HW/SW) Design
Cost, Schedule &
Program ManagementDRIVERS
Concept
Exploration &
Definition
Demonstration /
Validation
Engineering
Manufacturing
& Development
Production &
Deployment
Upgrade
and
Replace
nt
PHASE
1000
100
10
MGMT
Jan Apr Jul Oct
Structural / HME
Structural / HME
Distributed
Information
Repository
Other
System
Other
System
T&E
Engineering Development
& Manufacturing
Operations,
Logistics
& Training
ADVANCED COMBAT SYSTEMS
ADVANCED PLATFORMS
ADVANCED SENSORS AND WEAPONS

PBSA 效服績務採購 (Old Versus New
Process)
Traditional Process
Government Solves the
Problem
Performance-Based
Process
Contractor Solves the
Problem
Tight SOW
Rigid
Solution
Routine
Tasks
Formal
Systems
Competitive
Strategy
Use SOW
•PWS
•SOO
Innovative
Solutions
Share
Information
Collaboration
Strategy
Empower
Acquisition
Teams
Learning
Bureaucratic
Organizational
Change in service
Of Performance

績效服務契約績效服務契約 (PBSA)(PBSA)
採用績效服務契約採用績效服務契約 (Performance Based Service Contracting)(Performance Based Service Contracting) ，以量化，以量化
的的 Performance QuantityPerformance Quantity 規範規範 QualityQuality ；由於；由於 PBSAPBSA 條款，大部分美國政條款，大部分美國政
府的採購案已轉成採購單位只寫府的採購案已轉成採購單位只寫 Statement of ObjectivesStatement of Objectives 而由競標廠家寫而由競標廠家寫
Performance Based Statement of WorksPerformance Based Statement of Works （（ PSWPSW ）與）與 CDRLCDRL ，因為採，因為採
用量化方式，因此有助於採購的品質監控與驗收。用量化方式，因此有助於採購的品質監控與驗收。
甲方採購策略為：需求事項僅敘述終端之功能及量化之產品品質特性甲方採購策略為：需求事項僅敘述終端之功能及量化之產品品質特性
（（ PBSAPBSA ）、由乙方建議專案執行之參用標準、遂行專案發展過程之效能監）、由乙方建議專案執行之參用標準、遂行專案發展過程之效能監
控（控（ EVMSEVMS ）、）、 RFPRFP 須說明專案執行之相關程序事項（須說明專案執行之相關程序事項（ SOWSOW ）、）、 RFPRFP 須須
說明專案應交付物件（說明專案應交付物件（ CDRLCDRL ）、）、 RFPRFP 須說明交付文件之參考內容標準須說明交付文件之參考內容標準
（（ DIDDID ）、以工作分解結構（）、以工作分解結構（ WBSWBS ）為骨幹、）為骨幹、 .... 。。
PMPM 在參用在參用 PBSAPBSA 時，應一併規劃採購計畫書時，應一併規劃採購計畫書 AP (Acquisition AssuranceAP (Acquisition Assurance
Plan)Plan) ，， APAP 有關有關 PerformancePerformance 之敘述可包括下列事項：之敘述可包括下列事項：
1.1. 效能目標效能目標 Performance ObjectivesPerformance Objectives
2.2. 效能標準效能標準 Performance StandardsPerformance Standards
3.3. 允收標準水平允收標準水平 Acceptable Quality LevelsAcceptable Quality Levels
4.4. 檢視方法檢視方法 Methods of inspectionMethods of inspection
5.5. 檢視頻率檢視頻率 Frequency of inspectionFrequency of inspection
6.6. 獎勵金計算準則獎勵金計算準則 IncentivesIncentives

47
TRD
PM 所有相將關 Requirements 轉
入 RFP
Parts of an RFP
Section A Solicitation / Contract Form
Section B Supplies or Services / Prices /Costs
Section C Description / Specs / Work Statement
Section D Packaging and Marking
Section E Inspection and Acceptance
Section F Deliveries or Performance
Section G Contract Administration Data
Section H Special Contract Requirements
Section I Contract Clauses
Section J List of Attachments
Section K Contractor Representations &
Certifications
Section L Instructions, Conditions, and Notices
to Offerors
Section M Evaluation Factors for Award
APB/
ADM
ICD
CDD
SOO/
SOW
Acquisition Strategy Panel (ASP)
Market
Research
WBS
TRD
Risk
Mgt
Eval
Criteria
Acq. Strategy
or
Acq. Plan/SAMP
Sections
A - M
(Use to
develop)
(Reference)
(Included)
(As Applicable)
( 採購計畫基準 /
採購決策備忘錄 )
( 技術參考文文件 )
( 採購策略計畫書 /
採購管理計畫書 )
( 初步作需文件 ,
作需發展文件 )

02/22/16 國防工業發展協會48
RFP 與 Contract 關係
Requirements
Documented
specific
ops
needs
Evaluation Contract
Source
selection
evaluation
guide
Source
selection
plan
Source
selection
facility
Model
contract
(B–J + Att)
CSOW
Sy ste m-level
specification
IMP
CWBS
CDRLs
CLINs
MNS/SON
ORD/CRD
CONOPs
STAR
TEMP
RFP
Model
contract
(A–K + Att)
Section L-2
Section M
Sys perf
rqmts
SOO
WBS
Data rqmts
CLINs
SAMP, Acq Plan or
IPS SE Portions
P
c
T
A
CLINs
Proposal
erms and cond
lauses
Modify
dd (optional)
ropose options
Model
contract
(B–K + Att)
Proposal
volumes
CSOW
System-level
specification
IMP/IMS
IMP risk
approach
CWBS
CDRLs
Contractor Team SE
Policies and Practices

49
Acquirer’s System Engineering 扮演 User’s Needs 與
Developer’s Solution 之的間 Transformer

國防工業發展協會 50Slide 50
• Requirements Trade Studies and
• Effectiveness Analysis, etc.
• Physical Design Trade Studies
Systems Analysis
Assessments
• Functional Trade Studies and
Assessments
Requirements Analysis
• Define Requirements
• Define Interfaces
• Decompose and Derive Requirements
• Define Constraints & Conditions
• Define Requirements Architecture
• Establish Requirements Baseline
Functional Analysis & Allocation
• Define Functions
• Allocate Requirements to Functions
• Define Functional Interfaces
• Decompose Functions to Subfunctions
• Allocate Decomposed and Derived
Requirements to Subfunctions
• Define Functional Architecture
• Develop Functional Flow Block Diagrams
• Establish Functional Baseline
Physical Design & Allocation
• Define Subsystems and Components
• Allocate Functions and Subfunctions to
Subsystems and Components
• Define Subsystem & Component Requirements
• Define Subsystem & Component Interfaces
• Establish Allocated Baseline
• Define Physical Architecture
• Develop Physical Flow Block Diagrams
• Establish Physical/Product Baseline
JOC
Control
F11 F12 F31
F3F1
Sys
F2
I/F
I/F
I/F I/F
I/F
I/F
F32R22 R21
R2R1
Sys
I/F I/F
R22R11 C1 C2 C3
Sub3Sub1
Sys
Sub2
I/F
I/F
I/F I/F
I/F
I/F
• Risk Management
• Configuration & Data Management
• Interface Management
• Performance-Based Progress Measurement:
- SEMS/IMP & SEDS/IMS
- TPMs & Metrics
- Technical
Reviews
- Earned Value
Design LoopRequirements Loop
Verification Loop
Requirements Architecture Functional Architecture Physical Architecture
• SOW, Deliverables
• WBS, SBS, PBS
• Work & Planning Packages
Processes, Architectures, and Baselines
What is Systems Engineering? (cont)
and Assessments

傳統之需求工程傳統之需求工程

Develop Top-Level Requirements
Requirements
Analysis
Identify
Function
Requirements
Identify
Performance
RequirementsDefine
Measures of
Performance
Define
HCI
Identify Required
Infrastructure
Identify
Interfaces
Refine
Top-Level
Functions
Function
Analysis
Other
(Safety,
Training,
etc)

53

54
UNCLASSIFIED
UNCLASSIFIED
JO TNI
S TA FFCHIE FS OF

 OBJECTIVE:
 Attack targets in Urban Operations / CAS environments
– Buildings, moving vehicles, personnel
– Troops in contact
 REQUIREMENT: AFSOC Persistent Surface Attack System
of Systems (PSAS) Initial Capability Document (ICD)
 Network centric guidance
 Small, precise, multi-mission
 Reduced response time, minimal collateral effects
 Platforms
– JSF
– AC-130
– Persistent Surface Attack System of Systems
– Unmanned systems

56
UNCLASSIFIED
UNCLASSIFIED
JO TNI
S TA FFCHIE FS OF

PlanningPlanning
– Assess capabilities / review threatAssess capabilities / review threat
– Develop resource informed guidanceDevelop resource informed guidance
ProgrammingProgramming
– Turn guidance into achievable, affordable packagesTurn guidance into achievable, affordable packages
– Six-year program (Future Years Defense Program)Six-year program (Future Years Defense Program)
BudgetingBudgeting
– Assess for efficient funds executionAssess for efficient funds execution
– Scrub budget yearsScrub budget years
– Prepare defensible budgetPrepare defensible budget
Execution Review (incorporated in program/budget review)Execution Review (incorporated in program/budget review)
– Develop performance metricsDevelop performance metrics
– Assess actual output against planned performanceAssess actual output against planned performance
– Adjust resources to achieve desired performance goalsAdjust resources to achieve desired performance goals

58

國防科技專案管理(Iii)

Recommended

Recommended

More Related Content

Similar to 國防科技專案管理(Iii)

Similar to 國防科技專案管理(Iii) (20)

國防科技專案管理(Iii)

Editor's Notes