111 調查局特考三等 資訊科學組 系統分析與設計 考古題詳解

核心觀念

本題評量物件導向系統分析（OOA）中**使用案例規格／使用案例敘述（Use Case Specification / Description）**之設計能力。 在 UML 模型中，使用案例圖（Use Case Diagram）僅能呈現系統邊界、參與者（Actor）與功能目標的高階互動架構，無法呈現動態業務邏輯與細部步驟。因此，系統分析師必須輔以結構化的文字規格表（即操作概念與情境描述，常採 Alistair Cockburn 或 Craig Larman 之 Fully Dressed Use Case 格式），清楚定義前置條件、後置條件、主流程、例外流程與品質屬性，作為後續循序圖（Sequence Diagram）繪製、類別設計與測試案例撰寫的基礎。

---

解題方法

本題採兩階段切入：

1. 歸納核心欄位：扣除題目已明示的「使用案例名稱、使用案例代碼、主要角色、使用案例類型」後，依軟體工程標準範本，將常見欄位歸納為**「背景環境」、「狀態條件」、「互動流程」、「非功能與補充資訊」**四大面向，並逐一說明其標準名稱與精確定義。
2. 實例演繹：選定情境「網路報稅線上信用卡繳稅」，將上述各欄位填入符合台灣綜所稅電子申報與第三方金流授權的業務邏輯，展現完整的系統分析實務規格表。

---

選項分析

（本題為申論題，無選項分析。評分關鍵在於欄位涵蓋的廣度與定義深度，以及實例中「基本流程」與「替代／例外流程」是否具備嚴謹的互動時序與業務邊界邏輯。）

---

解題技巧

1. 欄位記憶口訣（前因後果、主副流程、角條非）：

• 角：次要角色（Supporting/Secondary Actors）
• 前：前置條件（Preconditions）
• 因：觸發事件（Trigger）
• 後：後置條件（Postconditions / Guarantees）
• 主：主要成功情境／基本流程（Main Success Scenario / Basic Flow）
• 副：替代／擴充／例外流程（Alternative / Exception Flows）
• 非：特殊需求／非功能性需求（Special / Non-Functional Requirements）

2. 實例撰寫陷阱：

• 流程描寫切忌寫成「UI 元件細節」或「程式碼實作」（例如避免寫「按下 button1 執行 SQL update」），應站在參與者意圖與系統責任的角度描寫互動步驟。
• 金流繳稅題型務必包含「次要角色（收單銀行／信用卡授權中心）」與「交易失敗／OTP 驗證逾時」等例外流程，方能拿滿分數。

---

【答案】

一、使用案例操作概念與情境之主要資訊欄位與定義

在排除題目已列欄位（使用案例名稱、代碼、主要角色、類型）後，標準使用案例規格表常包含下列資訊欄位：

1. 簡要說明（Brief Description / Summary）：

• 定義：以兩至三句話概括說明此使用案例的核心目的、功能範疇與預期達成的業務效益。

2. 次要角色／支援角色（Secondary / Supporting Actors）：

• 定義：在執行過程中協助系統完成目標的外部系統、硬體設備或外部單位（例如後端驗證服務、外部金流閘道）。

3. 利害關係人與利益（Stakeholders and Interests）：

• 定義：列出受本案例結果影響的所有人員或單位，以及他們所關注的核心目標（如稽徵機關要求稅款入帳、民眾要求取得憑據）。

4. 觸發事件（Trigger）：

• 定義：啟動該使用案例的事件或動作，可分為外部事件（使用者點擊某操作）、時序事件（定期批次處理）或狀態事件。

5. 前置條件（Preconditions）：

• 定義：在執行本使用案例前，系統與環境必須處於的初始狀態。若條件不滿足，該使用案例不可啟動。

6. 後置條件／保證成功狀態（Postconditions / Success Guarantees）：

• 定義：在主要流程順利完成後，系統資料庫或環境必須達到的最終狀態（例如資料更新、交易紀錄寫入、外部狀態同步）。

7. 主要成功情境／基本流程（Main Success Scenario / Basic Flow）：

• 定義：在沒有任何錯誤、分支與異常發生的情況下，主要角色與系統之間循序互動完成目標的最典型、最順暢步驟清單。

核心觀念

本題測驗「物件導向分析與設計（OOAD）」與「統一塑模語言（UML 2.x）」中的**互動圖（Interaction Diagram）**核心工具——循序圖（Sequence Diagram）。考點包含兩大面向：

1. 動態行為塑模時機：理解循序圖在系統分析與設計各階段（特別是使用案例實現、物件互動次序與跨程序溝通）的角色定位。
2. 訊息傳遞語意與標準符號學（UML Notation）：掌握程序控制流程（控制權轉移、阻塞與非阻塞）在「同步（Synchronous）」與「非同步（Asynchronous）」通訊下的行為差異，以及 UML 規範定義之線條形式（實線、虛線）與箭頭外觀（實心三角箭頭、單線開放箭頭）繪製標準。

---

解題方法

本題為標準的觀念闡述與圖形標記題，解答切入點分為兩大部分：

1. 循序圖使用時機：自「系統生命週期」與「模型視角」切入，條列其在需求分析、系統細部設計及分散式架構下的具體應用時機。
2. 同步與非同步訊息之詳細比較：採「定義與傳遞語意」、「繪圖符號規範」、「圖例示意」三層結構分別對照說明，確保論述清晰且圖文並茂，完全契合國考閱卷給分標準。

---

選項分析

本題為申論題（非選擇題）。評分核心在於觀念完整性與 UML 規範精確度，考生作答時應避免以下概念混淆：

• 同步訊息 vs. 回傳訊息之混淆：同步訊息是「實線 + 實心三角形」，而回傳訊息（Reply Message）為「虛線 + 開放箭頭」，兩者不可顛倒或省略回傳語意。
• 箭頭外觀之嚴格區分：UML 2.x 嚴格規定非同步訊息為「開放式單線箭頭（Line Arrowhead）」，同步訊息必須是「實心封閉三角形（Filled Solid Arrowhead）」，線條混用將嚴重失分。
• 生命線與活化長條（Execution Specification）之控制流：同步呼叫會造成發送端等待（阻塞），活化條持續延伸；非同步呼叫發送後發送端立即恢復獨立執行，接收端則獨立啟動自身之活化條。

---

解題技巧

1. 記憶口訣：

• 「同步等回覆，實心三角箭」：發送後阻塞等待，符號為實線配實心三角形（▲）。
• 「非同步各自走，單線開放箭」：發送後不等待，符號為實線配開放線條箭頭（$\rightarrow$）。
• 「回傳虛線引，開放箭頭回」：操作結果回傳，符號為虛線配開放線條箭頭（$\dashrightarrow$）。

2. 版面配置訣竅：申論題涉及「繪圖方式」時，除了文字定義，務必以 ASCII 圖或結構化線條圖直接畫出 UML 標記，並標明發送端與接收端的生命線（Lifeline）與活化長條（Activation Bar），能顯著提高閱卷分數。

---

【答案】

一、循序圖（Sequence Diagram）的使用時機

循序圖屬於 UML 動態行為模型，著重於以**時間序列（Time Sequence）**展示物件之間的互動行為。其主要使用時機如下：

1. 實現使用案例的具體情境（Use Case Realization）： 在系統分析階段，當需要詳細描繪某個使用案例（Use Case）的基本流程（Normal Flow）或替代流程（Alternative Flow）時，利用循序圖將抽象的使用案例步驟映射為具體物件角色之間的訊息互動。
2. 指派物件職責與精煉方法介面（Refining Class Responsibilities）： 在系統設計階段，透過循序圖釐清哪一個類別應負責提供特定的方法（Operation）。發送給特定物件的訊息名稱與參數，即可直接轉化為該類別的公開介面與方法簽章。
3. 塑模時間次序關鍵的複雜邏輯： 當業務邏輯具有高度時間敏感性、嚴格的呼叫先後順序或條件分支時，循序圖自上而下的垂直時間軸能直觀呈現流程演進，避免邏輯交錯。
4. 設計多執行緒、分散式系統與微服務通訊： 用於展示跨系統、跨行程（Process）的 API 呼叫、事件驅動架構（Event-Driven）或訊息佇列（Message Queue）通訊，清楚釐清系統元件之間的呼叫耦合性與時間相依性。

---

二、同步與非同步訊息之傳遞方式與畫圖方式

核心觀念

本題測驗「軟體工程流程改善」與「供應鏈網宇安全成熟度合規」之跨領域整合能力，評量重點包含：

1. 能力成熟度模型整合（CMMI, Capability Maturity Model Integration）：由美國國防部與卡內基美隆大學軟體工程研究所（SEI）研發（現由 ISACA 維護），本質為「以流程導向為核心的工程與專案管理改善架構」，評估組織在軟體開發、系統工程及服務交付上的成熟度。
2. 網宇安全成熟度模型認證（CMMC, Cybersecurity Maturity Model Certification）：由美國國防部（DoD）於 2020 年頒布（2021 年底宣布推行 CMMC 2.0），專為國防工業基礎（Defense Industrial Base, DIB）供應鏈設計，本質為「以控制措施落實為核心的強制性資安認證架構」，保護聯邦合約資訊（FCI）與受控非機密資訊（CUI）。
3. 成熟度架構比較：CMMI 之階層式（Staged）5 級模型與連續式（Continuous）能力等級；CMMC 之層級劃分（CMMC 1.0 之 5 級對比 2.0 之 3 級）、對應標準（NIST SP 800-171/172、FAR 52.204-21）及評鑑性質（流程制度化 vs. 資安技術控制項合規）。

---

解題方法

本題為標準的申論申覆題（申論四部曲：定義/目的 $\to$ 架構說明 $\to$ 差異比較 $\to$ 優缺點評析），解題切入點如下：

1. 目的說明：分別闡述 CMMI 與 CMMC 產生的歷史背景、發起機構、解決之痛點（CMMI 解決軟體品質不穩定與時程預算失控；CMMC 解決國防供應鏈漏洞引發之機密外洩）。
2. 成熟度等級拆解：

• 詳列 CMMI 之 5 個成熟度等級（初始、已管理、已定義、量化管理、最佳化）。
• 詳列 CMMC 架構（以國考命題當時主流及演進，點出 CMMC 1.0 的 5 個等級與 2.0 簡化後的 3 個等級：Foundational、Advanced、Expert），突顯對資訊敏感度（FCI/CUI）與對抗進階持續性威脅（APT）之防禦定位。

3. 成熟度差異比較：採「對比表格」搭配文字，從核心導向、涵蓋範圍、評鑑機制、等級意涵等維度精準對照。
4. 優缺點剖析：各自分項條列優點與缺點，直指業界導入痛點（如 CMMI 之文件化過重與 CMMC 之合規稽核成本過高）。

---

選項分析

本題為申論題（問答題），非選擇題。作答結構劃分為四大對應命題要素進行全面解析：

1. 要素一：CMMI 的目的：說明其以製程改善、品質控制、預測性管理為主要目標。
2. 要素二：CMMC 的目的：說明其為美國國防部採購之資安合規門檻，重點在保護非機密敏感資料與強化供應鏈縱深防禦。
3. 要素三：兩者成熟度之差異：對比「流程制度化（Process Institutionalization）」與「控制項實施（Practice Implementation）」的本質區別。
4. 要素四：兩者之優缺點：平衡評價兩者在實務推動上的效益（提升競爭力、強化防禦）與代價（高成本、維護負擔、中小企業進入障礙）。

---

解題技巧

1. 雙架構層級記憶口訣：

• CMMI 五等級：始（Initial）$\to$ 管（Managed）$\to$ 定（Defined）$\to$ 量（Quantitatively Managed）$\to$ 佳（Optimizing）。
• CMMC 2.0 三等級：基（Foundational，保護 FCI，17 項）$\to$ 進（Advanced，保護 CUI，110 項）$\to$ 專（Expert，對抗 APT，110+ 項）。

2. 評鑑機制之辨析陷阱：

• CMMI 評鑑多屬於「成熟度水準評定（Appraisal）」，重點在持續改善循環。
• CMMC 是「投標資格認證（Certification）」，未達標者無法取得美國國防部合約，具有強制性與一票否決性。

3. 版面配置技巧：差異比較務必使用 Markdown 綜合比較表，條理分明，利於閱卷委員在 30 秒內掌握完整給分點。

---

【答案】

一、CMMI 與 CMMC 之目的

1. 能力成熟度模型整合（CMMI）的目的

• 改善系統工程與軟體開發流程：協助組織評估並改善從需求分析、架構設計、編程、測試到維護的生命週期流程，降低專案時程延宕、預算超支與軟體瑕疵率。
• 建立流程制度化與可預測性：透過標準化、量化與持續最佳化的流程管理，使組織的生產力與交付品質不依賴個別明星員工，而是由組織的制度與文化保障。
• 提供國際公認之能力評鑑基準：作為全球軟體與系統整合商之能力成熟度衡量標準，協助發包單位客觀評選具備高成熟度開發能力的供應商。

2. 網宇安全成熟度模型認證（CMMC）的目的

• 強化國防供應鏈之資安防禦韌性：保護美國國防部（DoD）國防工業基礎（DIB）多層級供應商免受外國敵對勢力之網路攻擊與間諜滲透。
• 保護關鍵非機密敏感資訊：確保合約承包商與分包商具備足夠資安控制措施，防止聯邦合約資訊（Federal Contract Information, FCI）與受控非機密資訊（Controlled Unclassified Information, CUI）遭到竊取。

核心觀念

本題旨在測驗考生對於**能力成熟度模型整合（Capability Maturity Model Integration, CMMI）之核心架構及其在政府資訊委外治理（IT Outsourcing Governance）**實務中應用的理解。核心觀念包含：

1. CMMI 領域劃分：

• CMMI-ACQ（Acquisition，採購／發包）：專門提供給「買方（發包單位／政府機關）」的模型，指導組織如何進行招標規範訂定、供應商評選、合約管理、需求變更與驗收移轉。
• CMMI-DEV（Development，開發）：針對「系統開發廠商」，規範產品需求分析、系統架構設計、程式撰寫、單元與整合測試及發行。
• CMMI-SVC（Services，服務）：針對系統上線後的維運服務、日常事故處理與改版維護。
• 註：在 CMMI V2.0 框架下，上述領域整合成單一模型架構，並以「供應商協議管理（Supplier Agreement Management, SAM）」等實踐領域（Practice Areas, PAs）落實委外採購與監控。

2. 過程成熟度等級（Maturity Levels, ML 1～5）：

• Level 1 初始級（Initial）：臨時、混亂、依賴英雄主義。
• Level 2 管理級（Managed）：專案層級已獲管理，具備時程、成本、需求與組態管制。
• Level 3 定義級（Defined）：組織層級制定統一的標準委外開發程序與指南。
• Level 4 量化管理級（Quantitatively Managed）：以統計量化數據管制過程品質。
• Level 5 最佳化級（Optimizing）：持續創新與流程改進。

3. 委外開發與改版之治理目標：政府機關扮演發包與監管者角色，必須避免「範疇蔓延（Scope Creep）」、「進度失控」、「廠商綁標／單點失效」及「改版破壞既有架構」，確保委外專案如期、如質、如預算達成施政目標。

---

解題方法

本題為典型的系統分析與設計申論題，切入點應避免單純背誦 CMMI 五個成熟度等級，而須將 CMMI 的流程指引 具體結合 政府資訊委外開發與系統改版的生命週期。解題邏輯採「三維度展開」：

1. 角色界定與模型定位：釐清政府機關為「發包者（Acquirer）」，應運用 CMMI-ACQ（或 CMMI V2.0 之 SAM 領域）規範自身的管理機制；要求得標廠商具備 CMMI-DEV 能力，並在系統改版維運階段導入 CMMI-SVC。
2. 生命週期四階段落實規範：

• 準備與招標階段：藉由成熟度評級篩選合格廠商，訂定精確的需求規範書（RFP）。
• 合約與監控階段：建立客觀度量指標與定期查核點（Milestones），克服資訊不對稱。
• 改版與組態管理：落實需求變更控制與組態管理，保障既有業務連續性。
• 驗收與持續改善：進行嚴格的驗證與確認（V&V），並累積組織過程資產（OPA）。

3. 成熟度升級帶來的組織效益：闡述引進 CMMI 如何將個人經驗轉化為體制保障，達成如期如質之施政目標。

---

選項分析

本題為申論題（非選擇題），無固定選項。在申論佈局時，應針對題目提及之三大領域進行構面解析：

• 採購（Acquisition）維度：非僅限於法律招標程序，核心在於政府機關自身的「採購過程成熟度」，規範機關如何定義清晰的業務需求、控管供應商風險，是政府委外治理成敗的主導因素。
• 開發（Development）維度：用於要求並稽核承包廠商是否具備結構化工程實踐（如架構設計、單元測試、回歸測試），改版時必須具備向上與向下相容之設計規範。
• 服務（Services）維度：聚焦系統改版後的部署維運，透過建立服務水準協議（SLA）及問題管理機制，確保系統在改版過渡期不會中斷政府公務服務。

---

解題技巧

1. 避免常見陷阱（作答盲點）：

• 陷阱一：誤以為 CMMI 只是「廠商的事」。許多考生只寫「要求得標廠商具備 CMMI Level 3」，忽略了題目問的是「此模型如何指導或規範政府」。答題重心必須落在「政府機關身為發包單位，如何透過 CMMI 規範自身的發包管理與驗收流程」。
• 陷阱二：只背誦 ML 1～5 的定義。若僅平鋪直敘寫出五個成熟度階層名稱，無法拿到高分，必須點出具體的過程領域（Process Area, PA），例如 SAM（供應商協議管理）、REQM（需求管理）、CM（組態管理）、VAL/VER（確認與驗證）。

2. 架構化拿分公式：