111 司法特考三等 檢察事務官電子資訊組 系統分析 考古題詳解

核心觀念

1. AI/ML 時代系統分析師之新興技術趨勢： 傳統系統分析著重於關聯式資料庫（OLTP）與確定性業務邏輯（Deterministic Business Logic）。當機器學習（ML）與預測分析融入日常運營後，系統轉向非確定性、數據驅動與機率決策架構。系統分析師（SA）需具備將模型生命週期、即時數據管線、分散式雲端算力與資料治理整合進系統規格的能力。
2. 結構化分析方法論（Structured Analysis）與 DFD 階層化：

• 系統環境圖（Context Diagram）：亦稱背景圖，代表系統抽象層次的最高階。用以界定「系統範圍（Scope）」與「邊界（Boundary）」，僅包含單一處理程序（Process 0）、外部實體（External Entities）及兩者間的資料流，不得繪出內部資料儲存（Data Store）。
• 圖 0（Diagram 0 / Level-0 DFD）：由環境圖的 Process 0 進行功能分解（Functional Decomposition）而得，展開為主要子處理程序（如 Process 1, 2, 3...），並首次揭露系統內部的「資料儲存（Data Stores）」，必須遵循「父子圖平衡原則（Balancing）」。
• 建構順序：依據「由上而下（Top-Down）」的結構化分析原則，必須先界定邊界（環境圖），再細化內部架構（圖 0）。

---

解題方法

1. 第（一）小題：技術趨勢歸納與系統分析實務結合

• 從「模型維運化（MLOps）」、「資料架構現代化（Data Pipeline / Lakehouse）」、「微服務與事件驅動（EDA / API）」、「資料安全與隱私/治理（Governance & Privacy）」四個構面切入，突顯 SA 如何銜接演算法開發與生產環境系統之落地。

2. 第（二）小題：差異分析與建構程序論證

• 採結構化對比（處理程序粒度、資料儲存存在性、視角層次、編號慣例）。
• 論證「第一步」之歸屬：說明為何必須先從 Context Diagram 起步（界定範疇與利害關係人輸入輸出），以避免過早陷入內部實作細節（Analysis Paralysis）。

---

解題技巧與常見陷阱

• 名詞混淆陷阱：部分西方教科書習慣將 Context Diagram 稱為 Level 0、將 Diagram 0 稱為 Level 1；但國考標準教科書（如 Satzinger、Kendall & Kendall）通常嚴格區分：
• 最頂層代表整個系統的單一泡泡圖稱為 Context Diagram（環境圖）。
• 第一層分解出的主要功能圖稱為 Diagram 0（圖 0）。答題時務必分別精確定義，避免混為一談。
• DFD 繪圖禁忌（扣分地雷）：環境圖內絕對不可出現內部資料儲存（Data Store），除非該資料庫屬於外部系統（應畫為外部實體）。此點為閱卷委員評分時最關鍵的鑑別點，必須主動寫出。
• 平衡原則（Balancing）：在比較差異時，主動帶出「環境圖與圖 0 之間資料流必須平衡（輸入與輸出流完全對應）」的觀念，展現深厚的結構化分析底子。

---

【答案】

（一）系統分析師應持續關注之資訊技術發展趨勢

為因應機器學習與預測分析對 IT 運營之變革，系統分析師（SA）應持續掌握下列四大核心技術趨勢，以確保分析架構符合現代化生產環境之需求：

1. 機器學習維運化技術（MLOps / ModelOps）

• 內涵：涵蓋持續整合、持續交付與持續訓練（CI/CD/CT）流程，包含模型版本控管（如 MLflow、DVC）、特徵儲存庫（Feature Store）、模型漂移監控（Data/Concept Drift Detection）與自動化再訓練架構。
• SA 關注理由：預測模型並非靜態程式碼，其預測能力會隨時間與數據分佈改變。SA 在分析階段必須將「模型監控指標」、「回饋循環（Feedback Loop）」與「再訓練觸發機制」納入非功能性需求與系統生命週期規劃中。

核心觀念

本題出自民國 111 年公務人員特種考試司法人員考試三等考試（檢察事務官電子資訊組）「系統分析」考卷，主要測驗考生在「網路通訊架構」與「前端人機介面工程」兩大資訊系統核心基礎的掌握程度：

1. IEEE 802.11 無線區域網路拓撲（第（一）小題，15 分）：

• 考查 IEEE 802.11 標準定義的服務集（Service Set）架構，包含 BSS（Basic Service Set，基本服務集） 與 ESS（Extended Service Set，延伸服務集） 的拓撲組成、運作原理、識別機制（BSSID 與 SSID/ESSID）、骨幹分散系統（Distribution System, DS）之角色及第 2 層漫遊（L2 Roaming）能力。

2. 回應式網頁設計（第（二）小題，10 分）：

• 考查前端使用者介面（UI）與系統架構設計規範，著重於 回應式網頁設計（Responsive Web Design, RWD） 的核心定義、三大技術支柱（流動格線、彈性多媒體、CSS3 媒體查詢）、Viewport 設定以及在系統維護、SEO 與跨平台體驗上的優勢。

---

解題方法

1. 第（一）小題（BSS vs. ESS）：

• 定義切入：先分別界定 BSS（基礎構件，包含 Infrastructure BSS 與 Independent BSS/IBSS）與 ESS（由多個 BSS 透過 DS 串接組合而成的大型網路拓撲）。
• 多維度對比：採用「比較表格」搭配條列說明，從「實體範圍與組件」、「骨幹網路（DS）之需求」、「網路識別碼（BSSID vs. SSID）」、「漫遊支援度（Roaming）」與「系統擴充彈性」等維度進行嚴密區分，展現對網路底層通訊機制的掌握。

2. 第（二）小題（RWD）：

• 架構定義：闡明 RWD 由 Ethan Marcotte 於 2010 年提出，核心概念為「單一程式碼基底（Single Codebase）與單一 URL」，以因應多元終端螢幕尺寸。
• 三大核心技術機制：逐一論述 流動格線（Fluid Grids）、彈性圖片與多媒體（Flexible Images/Media）、媒體查詢（Media Queries），並補述 Viewport 視埠設定 與 行動優先（Mobile First） 策略，完整建立申論深度。

---

選項分析

本題為申論試題（非選擇題），無選項可供逐一分析。評分要點與論述重點對齊如下：

• 第（一）小題評分標準：
• 正確定義 BSS 的兩種型態（有 AP 的基礎架構模式、無 AP 的 Ad-hoc/IBSS 模式）。
• 精確指出 ESS 必須藉由 分散系統（Distribution System, DS） 互聯多個 AP。
• 明確對比 BSSID（48-bit MAC 位址）與 ESSID/SSID（邏輯網路服務識別名稱）之差異。
• 詳述 ESS 具備讓無線站台（STA）於同一個第 2 層網段內進行「無縫漫遊（Seamless Roaming）」的特性。
• 第（二）小題評分標準：
• 完整列出並精確解釋 RWD 三大不可或缺的技術成分（Fluid Grids, Flexible Media, Media Queries）。
• 指出 Viewport <meta> 標籤的作用機制。
• 對比傳統獨立行動版網站（m-dot 網站），說明 RWD 在系統分析層面的架構優點（維護性高、降低資料同步負擔、有利搜尋引擎最佳化）。

---

解題技巧

1. 結構化圖表展現專業度：無線網路拓撲題型切忌通篇純文字流水帳，答題時務必繪製對照表，並點出 DS（Distribution System）與 Roaming（漫遊）這兩個關鍵給分關鍵字。
2. 技術與架構思維並重：說明 RWD 時，除前端 CSS/HTML 技術外，應扣合「系統分析」學科的核心，帶入「系統開發生命週期維護成本」、「一致的 API / URL 資源架構」等軟體架構層級優點，能爭取閱卷委員給予高標分數。

---

【答案】

（一）BSS（Basic Service Set）與 ESS（Extended Service Set）無線拓撲的主要區別

在 IEEE 802.11 無線區域網路（WLAN）標準中，BSS 與 ESS 為不同階層的拓撲建構單位，兩者之主要區別分析如下：

1. 定義與組成結構不同

• BSS（基本服務集）：是 802.11 網路中不可分割的最基礎建構單元。
• 基礎架構模式（Infrastructure BSS）：由單一無線存取點（Access Point, AP）與多個關聯的無線站台（Stations, STAs）組成，所有終端通訊皆必須透過 AP 轉發。
• 獨立模式（Independent BSS, IBSS / Ad-hoc）：不需 AP，站台之間以點對點（Peer-to-Peer）方式直接通訊。
• ESS（延伸服務集）：是由兩個或多個基礎架構 BSS，透過**分散系統（Distribution System, DS）**互聯整合成的大型邏輯無線拓撲。對上層協定（如 TCP/IP）而言，整個 ESS 呈現為單一且連貫的區域網路（LAN）。

2. 骨幹連接機制（Distribution System, DS）不同

• BSS：屬於單一射頻單元內部運作，站台間或站台至 AP 僅透過無線射頻通道溝通，其本身不包含亦不依賴分散系統（DS）。
• ESS：**必須依賴分散系統（DS）**將各個 AP 串接。DS 通常為高速有線骨幹網路（如 IEEE 802.3 乙太網路），亦可為無線傳輸骨幹（如 Wireless Distribution System, WDS），負責在不同的 BSS 之間傳遞資料訊框。

3. 識別碼層級不同（BSSID vs. SSID）

• BSS 使用 BSSID（Basic Service Set Identifier）：長度為 48 位元，通常直接採用該 BS

核心觀念

本題評量軟體工程與系統分析中三大主流開發典範（Paradigms）之本質差異與特性評估：

1. 結構化方法（Structured Methodology）：以「程序／功能」（Process-oriented）為核心，將資料與演算法分開處理，遵循自頂向下（Top-down）的功能分解與瀑布式循序推進。
2. 物件導向方法（Object-Oriented Methodology, OO）：以「物件與實體」（Object-oriented）為核心，將資料（屬性）與操作（方法）封裝在一起，運用抽象化、繼承與多型建立高度可重複使用的模組。
3. 敏捷方法（Agile Methodology）：以「價值交付與人員協作」（Value-driven / People-centric）為核心，打破傳統計畫驅動（Plan-driven）的繁複文件架構，採時間盒（Timeboxing）、短週期疊代與漸增式交付（Iterative and Incremental），靈活應對需求變更。

---

解題方法

本題為標準的 25 分比較型申論題，答題架構應具備邏輯層次，切勿流於雜亂條列。建構切入點如下：

1. 破題對比（顯著區別）：先提煉出本質核心差異（思維典範、解構維度、生命週期哲學），並輔以「綜合比較對照表」，使閱卷委員能一目了然。
2. 分項論述（個別優缺點）：分別針對結構化、物件導向、敏捷方法，各提出 $2 \sim 3$ 點最關鍵且具代表性的優點與缺點，採用專業專有名詞（如高內聚低耦合、資訊隱藏、漣漪效應、時間盒、技術債等）。
3. 收尾總結：以一句話點明三者並非絕對對立，而是依專案規模、需求確定性與組織文化進行適性選擇。

---

選項分析（申論題各子題得分剖析）

本題為問答申論題，題目包含兩大核心子題，配分比重與解析重點如下：

1. 「最顯著的區別是什麼？」（約 10～12 分）：

• 結構化 vs. 物件導向：本質差異在於**「處理程序與資料是否分離」**。結構化視系統為「輸入－處理－輸出（IPO）」的階層程序；物件導向則以「狀態與行為的封裝實體」為系統單元。
• 預測型（結構化／傳統 OO）vs. 調適型（敏捷）：本質差異在於**「對待需求變更的哲學」**。傳統方法強調事前詳盡規格與計畫控制；敏捷方法強調迎抱變更、持續回饋與短週期工作產出。

2. 「它們各有什麼優缺點？」（約 13～15 分，各方法約 4～5 分）：

• 結構化：強在階層直觀、流程清晰；弱在資料暴露、需求變更易引發骨牌／漣漪效應。
• 物件導向：強在封裝、擴充與高度再用性；弱在抽象思維門檻高、初期設計成本龐大。
• 敏捷：強在快速回應變更、提早釋出商業價值；弱在文件不足、高度依賴團隊默契與客戶參與度，不易進行固定範疇的大型外包合約管理。

---

解題技巧

1. 圖表先行，論述在後：國考閱卷時間極短，於第一題部分直接繪製「三大多維度比較矩陣表」，能立刻展現扎實的基本功。
2. 善用指標性代表產出與工具破題：

• 結構化：資料流程圖（DFD）、結構圖（Structure Chart）、資料字典（DD）。
• 物件導向：統一塑模語言（UML）、使用案例（Use Case）、類別圖（Class Diagram）。
• 敏捷：使用者故事（User Story）、Scrum 衝刺（Sprint）、看板（Kanban）、燃盡圖（Burn-down Chart）。

3. 避免極端化評價：評論缺點時應客觀陳述其「適用邊界與限制」，而非單純批判過時。

---

【答案】

一、結構化、物件導向與敏捷方法之最顯著區別

三種軟體開發方法在核心哲學、系統解構視角及生命週期管理上有本質上的顯著差異，綜合比較如下表：

比較維度	結構化方法（Structured）	物件導向方法（Object-Oriented）	敏捷方法（Agile）

核心觀念

本題出自民國 111 年司法特考三等（檢察事務官電子資訊組）「系統分析」科目，測驗考生在軟體工程與資訊專案管理領域中，對**風險管理（Risk Management）**理論與實務運用的掌握程度。核心觀念涵蓋：

1. 專案風險（Project Risk）之定義：依據國際專案管理知識體系（PMBOK）與軟體工程標準，風險為兼具「不確定性（Uncertainty）」與「影響度（Impact）」之潛在事件。
2. 風險管理的三大核心任務：風險識別（Risk Identification）、風險分析與評估（Risk Analysis / Assessment）、風險因應與控制（Risk Control / Response / Monitoring）。
3. 兩階段風險分析之本質差異：定性風險分析（Qualitative Risk Analysis，主觀排序、風險矩陣）與定量風險分析（Quantitative Risk Analysis，數值機率、蒙地卡羅模擬、決策樹與預期貨幣價值 EMV）。

---

解題方法

本題為標準的專案管理申論題，應採取層次分明、條理清晰的論述結構：

• 子題（一）：從專案目標（範疇、時程、成本、品質）切入，點出風險的「不確定性」與「衝擊性」兩大要素，並以數理關係式說明風險暴險額（Risk Exposure）。
• 子題（二）：依循軟體工程經典生命週期（如 Boehm 與 Pressman 之架構），歸納出「識別」、「評估/分析」、「控制/因應」三大任務，並說明各任務之實務工作內容。
• 子題（三）：先個別定義定性與定量分析，再以系統分析師的角度，藉由「結構化比較表」從分析目的、評估依據、主要工具、產出結果及實務時機等維度切入，展現專業答題深度。

---

選項分析

本題為申論題，無選擇題選項。各子題評分重點與應答方向如下：

• 子題（一）：不可僅寫「發生危險」，必須精確寫出「不確定事件」及對專案目標之正面（機會）或負面（威脅）影響。
• 子題（二）：需清楚區隔管理程序的各階段，切勿將「分析」與「監控」混為一談，需呈現完整的回饋迴路。
• 子題（三）：務必列舉具體分析工具（如 P-I 矩陣 vs. 蒙地卡羅模擬），不可僅做抽象名詞解釋。

---

解題技巧

1. 關鍵字精準打擊：專案管理題型重在「專有名詞」。閱卷委員在評閱時會尋找關鍵字，如 Probability（機率）、Impact（衝擊）、Risk Matrix（風險矩陣）、EMV（預期貨幣價值）、Monte Carlo（蒙地卡羅模擬）。
2. 公式輔助說明：在定義風險時，輔以風險量化公式： $\text{Risk Exposure (RE)} = P \times I$ 能使論述具備理工與資訊學門的嚴謹度。
3. 善用對比表格：子題（三）的兩者差異若以純文字條列，容易版面雜亂；轉化為 Markdown 表格呈現，能大幅提升可讀性與專業度。

---

【答案】

（一）專案管理角度下之「風險」定義

在專案管理（依據 PMBOK 指南及軟體工程實務）的角度下，**風險（Risk）**被定義為：

「一項尚未發生、但具備不確定性（Uncertainty）的事件或狀況；一旦發生，將會對專案的至少一個目標（如範疇 Scope、時程 Schedule、成本 Cost、品質 Quality）產生實質的影響。」

風險具備以下核心特徵：

1. 雙重屬性（機率與衝擊）： 風險由「發生的可能性（Probability, $P$）」與「發生後的影響程度（Impact, $I$）」共同組成。在風險量化評估中，風險暴險額（Risk Exposure, RE）可表示為： $\text{RE} = P \times I$
2. 未來性與不確定性： 風險存在於未來。若某不利事件「已經發生」，則屬於「問題（Issue）」或「危機（Crisis）」，而非風險。
3. 雙向影響性： 在廣義專案管理中，風險包含負面衝擊的**「威脅（Threats）」以及正面效益的「機會（Opportunities）」**；在系統分析與軟體專案實務上，系統分析師通常重點聚焦於降低威脅。

---

（二）風險管理的三項基本任務

軟體工程與專案管理中，風險管理主要涵蓋以下三項基本核心任務：

1. 風險識別（Risk Identification）

• 核心內涵：有系統地主動發掘、辨認出專案生命週期中可能面臨的所有潛在風險，並詳細記錄其特徵。