Transcript N 2

第2章
系統工程程序
目錄
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
2.0 前言
2.1 系統工程程序之定義
2.2 系統工程程序前的準備工作
2.3 系統工程程序 (過程) 的十三個步驟
2.4 系統工程程序之簡化
2.5 系統工程執行中之技巧與手法
2.6 生命週期與SEP之關係
2.7 系統可行性分析
2.8 系統「可使用」之一些需求
2.9 統維修及補保
2.10 由TPM到品質屋
2.11 系統功能分析
2.12 如何做好工程上之取捨調整、擇衷優化
2.13 由系統合成到決策過程
2.14 總結
第2章 系統工程程序
2
2.0 前言
•
•
系統工程程序 (System Engineering Process,
SEP)，其實就是系統工程生命週期中，每一個
階段工作中之細步流程。
基本上系統工程程序 (SEP)，有至少以下五項特
性：
1.
2.
3.
4.
5.
由上到下 (Top-down)。
整合性。
全生命週期一式通用。
PDCA必須如影隨形 ── Feedback功能。
具重複運用 (Iterative) 流程之特點 ── 一有問題就要
用PDCA手法，做測試及驗證，反覆的使用以求改善
流程進而改進原產品。
第2章 系統工程程序
3
2.1 系統工程程序之定義
• 系統工程程序為系統工程管理過程中不斷出現
的一種反覆運算之邏輯過程 (Sequence)，經
由反覆運算的檢討，逐步經過不斷的測試與評
估 (Test and Evaluation)，最後把決策
(Mission Decisions) 轉換成為能代表此系統需
求之性能參數 (Performance Parameters)，
吻合決策所規劃的系統架構使顧客滿意
第2章 系統工程程序
4
2.2
系統工程程序前的準備工作
1. 確保系統定義和設計反應系統所有要素的要求，
即設備、軟體、人員、設施和資料的要求。
2. 綜合設計編組中各專家的技術工作，以產生一個
優化平衡的設計。
3. 提供全面的有從屬關係的系統架構，做為性能、
設計、介面、支援、生產和試驗的準則。
4. 為制定技術計畫和合約工作說明佐證。
5. 為後勤分析、整體後勤支援 (ILS) 的權衡研究和
後勤文件提供系統架構。
6. 為生產工程分析、生產性權衡研究以及生產 / 製
造文件提供系統參數。
7. 確保在設計過程的所有階段充分考慮生命週期費
用的問題和要求。
第2章 系統工程程序
5
美國國防部對系統工程之要求
1. 軍方和承包商雙方工程項目經理的相互理
解和支持。他們必須下決心把系統工程過
程做為整個開發工程項目的主要支柱。
2. 了解在各工程專業之間定義和相互聯繫。
3. 認識到MIL-STD-1521B中規定的正式技術
審查和審核的作用，包括每一正式審查和
審核的價值、目標和獨特的作用。
4. 具備工程項目目標方面的知識。
5. 徹底理解客戶要求。
第2章 系統工程程序
6
系統工程程序 (過程) 的十三個步驟
第2章 系統工程程序
7
系統工程程序 (過程) 的十三個步驟
• 確定需求
第2章 系統工程程序
8
系統工程程序 (過程) 的十三個步驟
•
系統可行性分析
1. 驗證並確定各種不同可能性的設計方法，是
否能達到當初的設計要求。
2. 尋找在表現效能、後勤考量及經濟的層面上
最有可能實現的方法或計畫。
3. 推薦出一個較好或是目前最好的方法。
第2章 系統工程程序
9
系統工程程序 (過程) 的十三個步驟
•
•
系統可操作性需求確認
維修及後勤支援
– 在一個完整的生命週期或全壽期中，行動及
維修約佔全部成本的一半，而隨著電腦的進
步，如何把維修及行動與全壽期整體考量及
全部電腦化，均為目前大眾及廠商的首要目
標。
第2章 系統工程程序
10
系統工程程序 (過程) 的十三個步驟
•
將技術性參數量化並排序
– 把任務需求轉化為量化之數據，且依重要性
或優先性，由前到後依序排列，以讓設計者
知道哪一個是他們要優先考量的。
•
•
•
•
功能分析
需求配當 (Requirements Allocation)
系統整合、分析及優化設計
設計整合
第2章 系統工程程序
11
系統工程程序 (過程) 的十三個步驟
•
•
•
•
系統 / 產品測試及評估 (Test & Evaluation)
(Validation，認證)
試製及量產
系統交客戶使用及整體後勤考量
系統交由客戶使用，考量可靠度，系統淘
除或再精進
第2章 系統工程程序
12
2.4 系統工程程序之簡化
第2章 系統工程程序
13
2.4 系統工程程序之簡化
•
以下是把此十三個步驟，經專家或大多計
畫之經驗得到可以簡化為以下面四個重要
步驟：
1.
2.
3.
4.
功能分析 (Functional Analysis)。
組合 (Synthesis)。
評估及決定 (Evaluation and Decision)。
系統基本諸元描述 (Description of System
Elements)。
第2章 系統工程程序
14
2.4 系統工程程序之簡化
•
其中各基本步驟再簡化如圖2-4所示。
第2章 系統工程程序
15
2.4 系統工程程序之簡化
•
把上列四項工作再做一延伸，透過執行之
經驗可以再精進為下面一張工作圖 (如圖
2-5)，其中有回饋表示要有回饋之機制
(Feedback)，即所謂PDCA之動作，左方
為輸入端，右方為輸出端，其中間之大方
塊即為一個SEP之過程。
第2章 系統工程程序
16
圖2-5
第2章 系統工程程序
SEP與輸入、輸出之關係
17
2.5
•
系統工程執行中之技巧與手法
在執行過程中要隨時注意反覆運作及平衡手
法 (Balance/Iterative-Operational,
Economic, Logstic)，隨時計算其間之指標
(Criteria)，經由分析來看是否合於需求。
1. 系統整合：以操作使用為優先，考慮各階段的介
面，輸入 / 輸出的關係。
2. 考慮關係時以：(1) 可互換性；(2) 具各項功能；
(3) 功能不重複後，才做整合。
3. 各項整合須滿足系統或上一層介面之需求。
4. 能夠應付外來的挑戰，把風險降到最小。
第2章 系統工程程序
18
系統工程程序之手法
1. 總輸入需求 ── 任務需求 (目標、環境、限制、
技術能力、最低效益指標)。
2. 四項基本步驟 ── 功能分析、組合、評估及決定、
系統基本諸元描述。
3. 三大分析 ── 後勤、壽期成本、生產工作。
4. 優點 ── 對文件資料及圖片有一致性、相關性及
可溯性，對技術要能預測、評估未來成長之空間，
看到未來之技術，如何使風險降到最低，減少因
計畫變更所造成對系統的不確定性。
第2章 系統工程程序
19
2.6 生命週期與SEP之關係
• 產品與生命週期
– 在此以光碟機為例來做說明
第2章 系統工程程序
20
• 系統工程是為了要完成一項明確之任務，有計
畫的將許多不同之個體組合在一元領導下的一
項工作。所以系統工程必須要注意，團隊以完
成總目標 (Object) 為主，次系統以合作無間、
充分協調為主，並不一定要最優秀之次系統，
或每一件都是最好之硬體，要求整合出來之產
品最滿足客戶之需求為總目標。
第2章 系統工程程序
21
週期及其生產審查過程
第2章 系統工程程序
22
2.7
系統可行性分析
• 可行性分析執行的時間是在概念設計之過
程中，只要可行，則在概念設計中就可大
家坐下來廣泛的討論。但是，一旦概念設
計結束，「定型」的產品就要出現，也就
是說，概念設計之結果一定有一組「可行」
之數據出現，而進到下一個初步設計之階
段。
第2章 系統工程程序
23
2.8
系統「可使用」之一些需求
1. 此系統要在何處或在何種環境下使用？
2. 使用此系統之場景 (Scenario) 及任務圖是否涵蓋？
3. 哪些技術指標或參數是你認為需關心的？
4. 使用此產品系統之方式是每天用幾小時？每月用
幾次？如何保養？
5. 系統執行第3. 點或第4. 點時，你認為之可靠度
(MTBF) 要多少才合乎你的要求，也就是說你對
系統之效益性指標 (System Effectiveness) 是多
少？
6. 在生命週期中如何執行？
7. 環境因素。
第2章 系統工程程序
24
2.9
第2章 系統工程程序
系統維修及補保
25
三種維修
1. O級維修 (Organizational Maintenance) 。
2. I級維修 (Intermediate Maintenance)。
3. D級維修 (Depot or Supplier Maintenance)。
依序，自己可以做的就是O級維修，若不行，
勉強送修就是I級維修，若到D級維修就要花
大錢，不但耗時，還有停工待料之危險
第2章 系統工程程序
26
2.10
•
由TPM到品質屋
滿足需求之三要件
1. 必須滿足客戶需求 ── 效益性的滿足
(Effectively)。
2. 必須滿足客戶需求 ── 有效率的滿足
(Effeciently)。
3. 在認證中 (Validation) 必須要做好能量、能測。
第2章 系統工程程序
27
圖2-7 任務TPM表
第2章 系統工程程序
28
• 圖2-7一方面可以量化，同時也可由上自下，
或下自上追查，以上僅為原則可提供顧客
參考，顧客與設計者間必須有良好之溝通，
溝通之語言最好是一組一組量化之數據，
雙方才不會雞同鴨講。
第2章 系統工程程序
29
品質屋 / 客戶與設計者之橋樑
•
在客戶與設計者間之必要溝通，使顧客之
聲音可以反映到最終設計上，所以必須要
建立一個工具可以：
1. 把一定要完成之需求以量化之方式，有權重
的依序列出。
2. 把需求一一轉化為技術參數。
第2章 系統工程程序
30
•
利用許多張表就可達成上述之目的 ：
1. 第一層圖表 ── 品質屋 ── 系統面之表達 / 說
明如何去做。
2. 第二層圖表 次系統品質屋 ── 就做些什麼事，
以量化方式說明。
3. 第三層圖表 ── 零件品質屋 ── 需要哪些零
件，以量化方式說明。
4. 第四層圖表 ── 製造品質屋 ── 製造要做些
什麼。
5. 第五層圖表 ── 行動支援品質屋 ── 說明行
動支援要做些什麼。
第2章 系統工程程序
31
圖2-8 第一層之品質屋
第2章 系統工程程序
32
圖2-9 品質屋圖表
第2章 系統工程程序
33
圖2-10 五層QFD圖
第2章 系統工程程序
34
2.11
系統功能分析
• 系統功能分析 (Functional Analysis)，即一
個系統有了，依圖2-1之十三個步驟流程表，
系統功能分析承上為TPM，即技術特性指
標為其輸入，而在本章之輸出為功能流程
表、時序表等。
第2章 系統工程程序
35
功能分析之重要性
•
生命週期之階段內，在研發階段，有概念設計，
然後就是初步設計。經過這兩個階段，配合上面
之結果，在此設計之輸出就是系統功能之量化描
敘 (System Functional Description)，其重要的
目的就是使做出來的系統，在任務上能發揮其技
術性能 (Performace)，使之與任務或需求一致，
而在本章所要講的功能分析 (Functial Analysis)
就著重其間不斷重複的反覆過程 (Iterative
Process)，這一層可以由系統面，分到次系統面，
一直分到最基層之性能表示，其間有以下兩點要
注意：
1. 一方面要滿足客戶原需求。
2. 一方面要滿足各介面、各分項間之約束性，即大家需
要互相退讓一步，才可讓系統繼續走下去。
第2章 系統工程程序
36
功能分析之目的
1. 根據客戶之需求，或作戰任務測試及製造之
需求，訂定系統功能之基準和性能需求 / 標
準。
2. 其次，是分析性能需求，並將其轉換成分配
到次系統或其他下屬 (基層) 之工作中。
3. 另外，功能分析也支援任務之分析工作，以
訂定功能之範圍、程序及相關之介面。
第2章 系統工程程序
37
圖2-11
第2章 系統工程程序
38
功能分析之主要內容
1. 功能確認 (Functional Idenfication)
–
在做分析需求時，必須找出何種功能一定要有單位去做
去執行，則主系統或總系統之目標才能達成，這個找出
的單位就是一個功能體，對上負責，對下嚴格執行。
2. 需求的下分配 (Requirement Allocation)
–
把最上層系統面之需求，逐層逐階的配當 (Allocate)到下
層，一直到該層可以解決特定之硬體或軟體之工作，直
接解決系統問題為止，其中包含：
(1)依功能需求，必須把設計一定配當「下援」。
(2)任務需求轉化為本系統或次系統專業之需求 (如可靠
度、維護度等)。
(3)把設計需求轉化為測試評估 (Validation) 之評估基準
(Baseline) (最小需求)。
第2章 系統工程程序
39
圖2-12 系統程序簡化之細目
第2章 系統工程程序
40
功能分析幾項重要工具
第2章 系統工程程序
41
第2章 系統工程程序
42
第2章 系統工程程序
43
第2章 系統工程程序
44
第2章 系統工程程序
45
第2章 系統工程程序
46
第2章 系統工程程序
47
•
除了以上功能流程方塊圖外，還有下列之重
要圖：
1. N2圖。
2. 時序表 (Time Line Sheet)。
•
時序圖，簡單來說，就是記錄系統功能流程圖之所有
關鍵時刻之時間「順」序「秩」序，在什麼時候才要
算是「關鍵時刻」？一般來說：
1.系統失效或異常之時間，前後即為關鍵時刻。
2.把此系統分析為次系統，此次系統之前後時效時間
也為關鍵時刻。
3.影響系統反應時刻之動能時刻。
4.任務切換時間。
5.需要進行時序分析時之最佳時刻。
第2章 系統工程程序
48
圖2-17
第2章 系統工程程序
49
2.12
1.
2.
3.
4.
5.
如何做好工程上之取捨調整、
擇衷優化
儘量使用現貨 (Off-the-shelf)
要及時突破瓶頸 (Bottleneck)
成本 ── 永遠是一個關鍵
零質設計 (Zero-mass Design)
第一次就做對 (Doing it right the first time)
第2章 系統工程程序
50
2.13 由系統合成到決策過程
第2章 系統工程程序
51