Transcript 第3章

第3章
系統工程之輸出文件與型態管理
目錄
•
•
•
•
•
•
•
•
•
•
3.0 前言
3.1 設計到位
3.2 規格的產出
3.3 生命週期與系統規格
3.4 把各項系統設計專案做整合
3.5 系統分析與控管
3.6 型態管理與設計管理
3.7 各階段之重要審查
3.8 計畫風險
3.9 總結
第3章 系統工程之輸出文件與型態管理
2
3.0 前言
•
整體系統設計需求中，不外乎六大項：
1.
2.
3.
4.
5.
6.
確定需求。
可行性分析。
確定可操作之方便性維修制度之建立。
技術性能參數之排序及評量 (TPM)。
功能分析。
把需求由最上層「當」到深底層。
第3章 系統工程之輸出文件與型態管理
3
3.0 前言
•
其中所要做的工作 (Activities) 有四項要事
不離手：
1.
2.
3.
4.
合成、分析 (Synthesis)。
分析。
優化(Optimal)。
擇衷優化 (或取捨) (Trade-off)。
第3章 系統工程之輸出文件與型態管理
4
•
從生命週期中之研發的角色來切入，就研
發或從工程發展而言，就有三個階段：
1. 概念設計 (Conceptional Design)。
2. 初步設計 (Preliminary System Design)。
3. 細步設計 (Detail Design/Development)。
第3章 系統工程之輸出文件與型態管理
5
圖3-2產品生命週期與規格關係圖
第3章 系統工程之輸出文件與型態管理
6
3.1 設計到位
•
•
如何讓設計出來的東西「到位」，有無標
準，那就是規格文件之產出，系統工程程
序之團隊，就是訂出一文件之團隊，若需
求一定，確定經過，第一回合系統工程序
之執行，其輸出的「產品」就是系統規格，
我們叫做A-S/P，A規格。
對系統需求而言，一旦轉換成量化之數據，
它有兩層意義：
1. 制式的規格 (Specification)。
2. 計畫文件 (Planning Documentation)。
第3章 系統工程之輸出文件與型態管理
7
• 前者為系統工程之技術文件，即做出來的
「東西」，必須滿足哪些量化之數據，而
後者則是系統工程管理之工作，必須在有
限之資源下來完成前項之工作，現在就用
說明及圖表之方式來說明規格是什麼。
第3章 系統工程之輸出文件與型態管理
8
3.2
規格的產出
1. 系統之規格 (System Specification) (A規
格)
2. 發展規格 (Development Specification) (B
規格)
3. 產品規格 (Product Specification) (C規格)
4. 製程規格 (Process Specification) (D規格)
5. 材料規格 (Material Specification) (E規格)
第3章 系統工程之輸出文件與型態管理
9
圖3-3 某一系統之規格數據
第3章 系統工程之輸出文件與型態管理
10
3.3 生命週期與系統規格
•
系統工程以文件 (Document) 為其輸出，
一般而言其文件依特性有以下四種：
1.
2.
3.
4.
需求文件 (Requirements)。
配當文件 (Allocation)。
技術評估文件 (Assessment)。
規則文件 (Plans)。
第3章 系統工程之輸出文件與型態管理
11
表3-1 系統工程文件內容表
第3章 系統工程之輸出文件與型態管理
12
•
生命週期中之各階段 (Phase) 與產出之規
格，在時間點上是十分有關的。
1. A規格之產出時間
•
在概念設計中，可針對各種之可行性做天馬行空或
萬花爭放式的討論，但到概念設計之末端時，必須
收歛出一種「型態」，或一種產品之外型。一旦收
歛定型，則為「概念設計」之輸出，即A規格，因為
在此規格中，確定了系統「所有」的技術需求
(Technical Requirements)。
第3章 系統工程之輸出文件與型態管理
13
圖3-4 技術規範樹分解表
第3章 系統工程之輸出文件與型態管理
14
2. B規格之產出時間
•
B規格又叫做發展規格 (Development
Specification)。在其中確定系統之性質、設計工
程發展及測試需求。當將來稽查小組做FCA
(Functional Configuration Audit) 來稽查時，就要
來審查此項規格，看看系統之需求與次系統細部
設計之相關狀況是否一致。
3. C、D、E規格產出之時間
•
所謂實體型態稽核 (Physical Configuration Audit,
PCA)，在審核時，就要確定產品，是「確實」依
C、D、E規格來執行「量產」之工作。
第3章 系統工程之輸出文件與型態管理
15
• FCA及PCA在產品正式進入量產前，是必
須要做的工作，這也是系統工程之優點，
讓客戶知道工程設計到此階段，做一個決
定，有無足夠的能力進入量產
第3章 系統工程之輸出文件與型態管理
16
表3-2 生命週期與審查關係圖
第3章 系統工程之輸出文件與型態管理
17
3.4
把各項系統設計專案做整合
第3章 系統工程之輸出文件與型態管理
18
•
如何把各項系統設計專案做整合，這是一
項十分困難之工作，系統工程師發揮其專
長就在這裡，一個系統工程師至少要具備
以下「天份」：
1. 對各項專業有能力去發掘，以完成最終之整
合工作。
2. 在各項不同之專業「間」，對介面之處理，
要有「極佳」之協調能力。
3. 系統工程師要做到像樂團之總指揮那樣使下
面聽話
第3章 系統工程之輸出文件與型態管理
19
3.5
•
•
系統分析與控管
一個系統前面提及在概念設計之尾A規格要出來，在初步
設計之尾B規格要出來，這些規格出來，才能開始工作，
執行V型圖中之步驟。
在系統控管中之重點 ── 型態管理 (Configuration
Management)。在講型態管理之前，首先對分析及控管
所做之工作在此先做一個說明。
1.
2.
3.
4.
5.
6.
7.
完成WBS (Work Breakdown Structure)。
做好型管 (Configuration Management) (或說構型管理)。
工程審查及稽核 (Technical Reviews and Audits)。
擇衷優化分析 (Trade Studies)。
模式確定與模擬 (Modeling, Simulation & Emulation)。
TPM 及品質屋之展開。
風險管理 (Risk Management)。
第3章 系統工程之輸出文件與型態管理
20
3.5
系統分析與控管
• 從週期立場來看，在概念設計及研發 (R&D)
之階段就是進入展示確認、硬品要出來的
時候，因此，型管就十分重要。
第3章 系統工程之輸出文件與型態管理
21
3.6 型態管理與設計管理
•
•
型即型態 (Configuration)。仍指產品的功
能特性與實體特性
型管之定義
– 在系統之生命週期 (全壽期) 中，利用現有之
能量與技術對產品軟硬體之功能及實體特性，
執行下列四項工作作為之過程：
1.
2.
3.
4.
型態確定。
型態變更管制。
型態現況。
型態稽核。
第3章 系統工程之輸出文件與型態管理
22
•
型管識別包含以下四項工作：
1.
2.
3.
4.
型態項目之選擇 (依據及核頒)。
建立構型基準 (Baseline) 及型態文件。
訂定型態項目及文件之識別編碼。
型態及其文件清單之建立。
第3章 系統工程之輸出文件與型態管理
23
圖3-6
第3章 系統工程之輸出文件與型態管理
24
• 如表3-3，依上面之諸規格，所定妥之量化
數據即為基準 (Basline)，但還有所謂「現
行」基準，即為在基準下，配合「目前」
核可之變更，就成為「現行」之基準，有
了基準才能做型態之基準，才有依據，後
面才能確認，才可管制。
第3章 系統工程之輸出文件與型態管理
25
表3-3
第3章 系統工程之輸出文件與型態管理
26
• 在工程管制之流程中，首先要了解管制之
對象至少有二，首先要管制藍圖，其次要
管制零件之清單。由系統工程之生命週期
中，先是在設計上面做管制，再來則是計
畫上做管制，最後則在製造上做管制，這
三段管制流程，如圖3-7表示。
第3章 系統工程之輸出文件與型態管理
27
圖3-7
第3章 系統工程之輸出文件與型態管理
28
• 要注意的是一個產品必須要「配當」到每
一個元件，元件又配有其該有之最新版之
藍圖，這其中之表格以BOM表表示為最常
用，但此BOM要隨時更新，到PDCA之跟
催，否則BOM表做的再「好看」也是「不
適用」的。
第3章 系統工程之輸出文件與型態管理
29
型態變更管制 (Configuration
Change Control)
• 此項管制之目的，是防止偏異之不正常出
現，如果出現要如何做管制，防止因變異
量而使型態變更，發散到無法受檢之地步，
此項工作首先是要成立委員會，成立後就
要負起責任來做偏異量或變更之審查及核
定，這裡必須注意，其中必須要有變更之
等級及分類 (分A級及B級變更)。
第3章 系統工程之輸出文件與型態管理
30
• 如果廠商做出之精度無法滿足藍圖之規定 ，就必
須要做偏異申請或工程變更。在此要先定義偏異
量之分類，一般可分為三項：
1. 嚴重性 (Critical) 之變異 ── 會影響產品之成敗或安全。
2. 重大性 (Major) 之變異 ── 其中又包括：
1)
2)
3)
4)
5)
6)
健全性。
性能。
互換性、可靠度，及維護度。
使用或操作之範圍。
重量。
外觀。
3. 輕微的 (Minor) 之變異：不會影響整個系統之性能。
第3章 系統工程之輸出文件與型態管理
31
•
一旦出現問題，就必須要開會討論，是退
貨、還是減價驗收、還是接收，這又有一
個過程，對審查來講又有以下三個方式：
1. 嚴重或重大異常 ── 以一級變更之方式審查。
2. 輕微的設計異常或偏差 ── 按二級變更之方
式審查。
3. 輕微的製造異常。
第3章 系統工程之輸出文件與型態管理
32
型態現況之反應，及現況錄報
• 其目的是做定期性之記錄及報告，以提供
系統在研發及各階段之型管資料，以確保
型態之項目及搬運到手之最終物件確定是
合乎需求的，絕不可以有東西運過來，不
是自己要的，或版本不合而「強迫」接受。
第3章 系統工程之輸出文件與型態管理
33
圖3-8
型態管理現況回報流程圖
第3章 系統工程之輸出文件與型態管理
34
型態管理介面 ── 型態稽核之重點
第3章 系統工程之輸出文件與型態管理
35
圖3-10
型管之控管小組 (CCB) 之
工作流程圖
第3章 系統工程之輸出文件與型態管理
36
•
型態稽核 / 查 (Configurate Audit)
1. PCA (實體型態稽核)：為建立生產與接收商
品之型態文件，並明訂產品接收測試之各項
需求。
2. FCA (功能型態稽核)：確證所有功能文件可
達到系統規格，並掌握測試分析之相關文件。
3. SVR (System Verification Review)。
第3章 系統工程之輸出文件與型態管理
37
圖3-11
第3章 系統工程之輸出文件與型態管理
38
系統配當之層次
• 一個系統資料依MIL-STD-280之規定可分
為下列諸層：
1.
2.
3.
4.
5.
6.
7.
8.
系統 (System)。
次系統 (Sub-system)。
群集 (Set)。
群 (Group)。
單體 (Unit)。
組合件 (Assembly)。
次組合件 (Sub-assembly)。
零件 (Part)。
第3章 系統工程之輸出文件與型態管理
39
執行型管之準則及要求
1. 型態管理之目標
1) 以最低成本、最少資源達成各項目之需求。
2) 在型管 (生產、後勤) 條件下，提供最大之工
程發展空間。
3) 在管制工程修改後，可使全計畫獲最大效益
(Effectiveness)。
4) 使客戶 / 使用者、計畫主持人、承包商在型態
管理上同步，語言及版本一致。
第3章 系統工程之輸出文件與型態管理
40
2. 計畫必須成立型管小組 (如圖3-12)
1) 計畫主持人，即型管小組組成。(直接領導)
2) 專案計畫應在計畫室內成立分項小組。
3) 各分系統 (功能編組) 主管應有聯絡小組在內
工作。
4) 型管委員會要成立。
第3章 系統工程之輸出文件與型態管理
41
圖3-12 虛擬組織分工之架構圖
第3章 系統工程之輸出文件與型態管理
42
在各發展階段中，型管工作之內容
及項目
第3章 系統工程之輸出文件與型態管理
43
第3章 系統工程之輸出文件與型態管理
44
第3章 系統工程之輸出文件與型態管理
45
資料管理
• 資料管理，其實英文為 “Data
Management”，嚴格應該說是量化的數據
或規格管理，其主要之目的是保持產品由
研發到製造之生命週期過程中的資料庫要
一直保持「最新」，以支持全系統在各階
段下做決定、訂定方法、回饋追蹤及型管
之用。而在管理上面廣義之資料，不是指
數據，而是廣泛之資訊 (Data)。
第3章 系統工程之輸出文件與型態管理
46
•
在系統工程中之資料，來自各個階段或實
驗後之記錄，各種協調設計下大眾認可之
數據特性，以及在各管理階層會議中之結
論，或有關財務報表、科學及工程面之資
料，甚至後勤資訊以及由合約商那裡送出
來之有關文件等。這些資料有三種方式：
1. 技術資料。
2. 非技術資料。
3. 僅用一次 (One-time) 之資料。
第3章 系統工程之輸出文件與型態管理
47
•
這些資料之使用有兩個目的：
1. 讓資訊流 (Information) 可依前述PDCA方式
做回授，對合約商、計畫管理控管上有追蹤、
查詢的好處。
2. 在生命週期各階段之管理、後勤系統之支援
上，有很多時間在系統工程程序流中應做決
策時，能提供重要之數據，供管理者參考。
第3章 系統工程之輸出文件與型態管理
48
3.7
•
各階段之重要審查
重要審查會議之內容及重點
1. SRR會議 (System Requirements Review) ── 在展
示確認期完成。
2. SDR會議 (System Design Review) ── 在展示確認末
期要完成。
3. PDR會議 (Preliminary Design Review) ── 在工程發
展階段要完成。
4. CDR會議 (Critical Design Review) ── 在工程發展階
段要完成。
5. FCA會議 (Function Configuration Audit) ── 在工程
發展階段要完成。
6. PCA會議 (Physical Configuration Audit) ── 在工程
發展階段要完成。
第3章 系統工程之輸出文件與型態管理
49
3.7
各階段之重要審查
7. FQR會議 (Formal Qualification Review) ──
在量產前或開始時一定要完成。
8. CDR會議 (Conceptual Design Review) ──
在工程發展階段要完成。
9. EISDR會議 (Equipment / Software Design
Reviews)。
10. SFR會議 (System Function Review)。
11. SSR會議 (Software Specification Review)。
12. SVR會議 (System Verification Review)。
第3章 系統工程之輸出文件與型態管理
50
•
在圖3-13中，可看到SRR一般執行之時間是在概
念設計結束。在展示確認的階段內，任何時間可
以來做SRR，而此SRR之內容為系統需求審查
(System Requirements Review, SRR)，其中有
四件事情要做：
1. 要雙方了解合約之需求 (Contract Requirements)。
2. 要知道客戶要什麼 (Customer Desires)。
3. 系統功能及需求要：
1) 量化。
2) 文件，規格化。
4. 其「會審」之紀錄要三讀通過並「凍結」或「固定」
系統規格。
第3章 系統工程之輸出文件與型態管理
51
圖3-13
第3章 系統工程之輸出文件與型態管理
52
系統需求
第3章 系統工程之輸出文件與型態管理
53
表3-6
不同的審查名稱相同之內容表
第3章 系統工程之輸出文件與型態管理
54
介面審查文件 (ICD)
•
介面管理其內容為：
1. 確定介面之內容、數量、關係 (用 表)。
2. 建立工作團隊來管理介面。
3. 完成介面控管之文件。
第3章 系統工程之輸出文件與型態管理
55
• 在執行之步驟上：
1. 首先要做介面確定之工作，這個介面就是實體的、功能性
的、電子的、機械的、液壓的、軟體的……等，一旦不同
次系統間就此有介面，更何況次系統與組件間更是重要。
2. 成立介面控管團隊 (Interface Control Working Group,
ICWG) 做為系統與組件間聯絡之工作站，做意見之交換
與溝通。
3. 做好介面文件之控管 (Interface Control & Documentation,
ICD)。其中重要為藍圖之控管，使不同分系統或元件圖
「型」、「性」、「資」要一致，則包裝上才不會出錯，
此點「痛苦」很多，團隊必須要特別留意才行。
4. 開發、系統、介面標準之建立 / 要讓介面之間之「衝擊」
為最小，在第2章產品優化之過程中就有提到，要儘量用
「標準件」或現有商品，才可把「介面」問題降到最小。
第3章 系統工程之輸出文件與型態管理
56
3.8 計畫風險
• 在計畫執行之過程中，可以因時程、經費
或性能，無法達成預期之目標，而使整個
計畫失敗或中途停頓，這就是風險。
第3章 系統工程之輸出文件與型態管理
57
• 風險必須要做分析和及時「忠誠」管理，
使既有之風險變小，原小之風險消失，這
也是用系統工程之方式把莫非定理中之損
失降至最小之方法 (如圖3-14)。
第3章 系統工程之輸出文件與型態管理
58
圖3-14 風險管制流程表
第3章 系統工程之輸出文件與型態管理
59
風險管理要做的工作
1. 風險管理目標。
2. 任務編組。
3. 執行管制 ── 先要做風險估算，把系統風
險配當到各分系統中提出分層之項目，再
依各分系統或功能單位之經驗及專業來判
斷對計畫或系統在管理上有哪些衝擊，再
提出管制辦法來。
第3章 系統工程之輸出文件與型態管理
60
風險分析
1. 依發生之機率層級來做分析 ── 說明判斷
風險發生的理由。
2. 分析失敗後果之層級 ── 分析每一個風險
項目在風險發生後，對性能、功能、時程
及成敗之衝擊與影響。
3. 評定風險的等級 (Risk Rating)。以美國太
空總署 (NASA) 的太空梭為例，在風險管
理上面，把風險分為七等 (如表3-8)
第3章 系統工程之輸出文件與型態管理
61
表3-8
第3章 系統工程之輸出文件與型態管理
62