111 地方特考三等 資訊處理 系統分析與設計 考古題詳解

核心觀念

本題評量結構化系統設計（Structured System Design）中衡量模組獨立性（Module Independency）的兩大核心指標：內聚力（Cohesion）與耦合力（Coupling），並要求使用**結構圖（Structure Chart）**進行視覺化建模。

1. 模組獨立性準則：

• 優良的軟體架構目標為**「高內聚、低耦合（鬆散耦合）」**（High Cohesion, Loose Coupling），能使系統達到易讀、易測、易維護與高重複使用性。

2. 內聚力（Cohesion）：

• 定義：衡量單一模組內部各項元素（指令、函式、資料）彼此關聯與聚焦於單一任務的緊密程度。
• 等級光譜（由最高至最低）：功能性內聚（Functional）$>$ 循序性內聚（Sequential）$>$ 溝通性內聚（Communicational）$>$ 程序性內聚（Procedural）$>$ 時間性內聚（Temporal）$>$ 邏輯性內聚（Logical）$>$ 偶然性內聚（Coincidental）。
• 最高內聚力代表：功能性內聚（Functional Cohesion），模組僅執行一項且僅此一項定義明確的單一運算或任務。

3. 耦合力（Coupling）：

• 定義：衡量不同模組之間彼此相依、互相呼叫及資訊傳遞的緊密程度。
• 等級光譜（由最鬆散/最佳至最緊密/最差）：資料耦合（Data）$<$ 戳記耦合（Stamp）$<$ 控制耦合（Control）$<$ 外部耦合（External）$<$ 共同耦合（Common）$<$ 內容耦合（Content）。
• 最鬆散耦合代表：資料耦合（Data Coupling），模組間僅透過參數列傳遞不可分割的基礎純資料項目（Primitive Data），完全不傳遞任何控制旗標（Control Flags）或複合資料結構。

4. 結構圖（Structure Chart）符號規範：

• 模組（Module）：以矩形框表示，命名採「強動詞＋單一名詞」。
• 呼叫連線（Call Line）：以有向線段或箭頭由上層模組指向下層模組。
• 資料耦合（Data Couple）：箭頭尾端帶有空心圓（$\circ\longrightarrow$），表示純資料參數傳遞。
• 控制耦合（Control Couple）：箭頭尾端帶有實心圓（$\bullet\longrightarrow$），表示控制旗標或決策信號傳遞。

---

解題方法

本題為申論繪圖題，作答策略分為兩大部分：分別給出「高內聚力」與「鬆散耦合」的實例，繪製標準結構圖並搭配文字說明其機制與優點。

1. 高內聚力實例設計：

• 選取最佳等級之功能性內聚（Functional Cohesion）。
• 設計主控模組「計算訂單總額」，其下分解出專職專責的子模組，例如「計算商品折扣」與「計算加值稅額」。
• 繪製結構圖時，凸顯子模組職責單一、無副作用。

2. 鬆散耦合實例設計：

• 選取最佳等級之資料耦合（Data Coupling）。
• 設計主控模組「結算員工薪資」呼叫專門計算模組「計算加班費」。
• 繪製結構圖時，明確標記空心圓箭頭（Data Couple），展示僅傳遞必要純量數值（如「加班時數」、「時薪」），並回傳純量「加班費」，無任何實心圓控制旗標（Control Couple），亦不依賴全域變數。

---

結構圖繪製與實例說明

一、高內聚力（High Cohesion）實例：功能性內聚

1. 結構圖繪製

 ┌─────────────────┐
 │ 計算訂單應付總額 │
 └────────┬────────┘
 │
 ┌─────────────┴─────────────┐
 │ │
 ┌──────▼──────┐ ┌──────▼──────┐
 │ 計算商品折扣 │ │ 計算加值稅額 │
 └─────────────┘ └─────────────┘

2. 文字說明

• 模組職責：
• 計算商品折扣：該模組只專注於單一運算任務，依據輸入之會員等級與金額，純粹執行折扣公式計算。
• 計算加值稅額：該模組完全獨立，僅針對稅前淨額乘上法定稅率，執行單一稅額計算。
• 高內聚特徵：
• 此設計屬於功能性內聚（Functional Cohesion）。每個模組內部程式碼高度聚焦於完成單一、不可再分割的功能目標。
• 模組命名皆為具體的「動詞＋特定名詞」，模組內部沒有包含與本身無關的動作（例如在計算折扣時兼做發票列印或資料庫連線更新）。
• 優勢：
• 易於單元測試（Unit Test）：輸入與輸出關係純粹。
• 高重複使用性（Reusability）：任何需要計算營業稅的流程皆可直接取用該模組。
• 維護性極高：稅率或折扣政策調整時，僅需修改特定單一模組，不影響系統其他部分。

---

二、鬆散耦合（Loosely Coupled）實例：資料耦合

1. 結構圖繪製

核心觀念

本題出自民國 111 年公務人員特種考試地方政府公務人員考試（三等・資訊處理類科）《系統分析與設計》，主要評量考生在軟體採購規劃、資訊委外管理（Outsourcing Management）及資通安全治理之實務整合能力。

1. 服務水準協議（Service Level Agreement, SLA）： 源自 ITIL（資訊架構圖書館）服務設計與營運管理核心概念。SLA 是服務提供者（廠商）與需求者（機關/客戶）之間簽訂的具法律約束力協議，明確規範服務範疇、品質標準、衡量指標（SLI）、目標值（SLO）以及未達標之補償與懲罰條款。
2. 委外資通安全管理規範： 以命題當年（民國 111 年）法規為準，本題緊扣《資通安全管理法》第 9 條及《資通安全管理法施行細則》第 4 條對公務機關辦理委外業務之要求，以及行政院公布之《資通安全責任等級分級辦法》委外辦理資通系統之安全控制措施。 註：現行法規中，數位發展部已持續更新相關防護基準與契約範本，但解題核心仍以命題當年規範與通用的安全軟體開發生命週期（SSDLC）及 ISO/IEC 27001 供應商安全管理架構為準。

---

解題方法

1. 子題 (一) 切入點：

• 採「定義與角色功能 $\to$ 核心指標量化 $\to$ 具體實務範例」之三段式架構。
• 深入說明 SLA 不僅是合約附件，更是「服務邊界劃分」、「營運風險管控」、「驗收與計費衡量」、「持續改善驅動力」的關鍵工具。
• 實例必須具體，不可僅泛稱「系統要穩定」，應列出明確指標（如系統可用度、平均修復時間 MTTR、資安事件應變時限）。

2. 子題 (二) 切入點：

• 避免雜亂條列，應依循系統生命週期（SDLC）階段鋪排，涵蓋「合約與規範」、「開發」、「測試」、「運作（營運）」及「稽核驗收」，歸納出 5 項互不重疊且直擊資安風險的重要措施。
• 緊扣題目關鍵字「開發、測試、運作」，各階段皆提出對應之技術與管理防護（如安全程式碼檢測、測試資料去識別化、最小權限控管、第三方弱點複測）。

---

選項分析

本題為非選擇題（申論題），無選項可供分析。評分與給分關鍵剖析如下：

• 子題 (一) 評分關鍵（佔 10 分）： 若僅回答 SLA 的名詞解釋，僅能獲得基礎分數（約 3～4 分）；欲拿高分，必須完整點出其在系統營運維護中所發揮的「責任歸屬、監控基準、違約罰則」角色，並輔以具體數值實例（例如：可用率 $99.9\%$、復原時間目標 RTO、資安通報時效）。
• 子題 (二) 評分關鍵（佔 10 分）： 題目明確要求「5 個重要措施」，閱卷評分通常採一項 2 分計算。若措施過度集中於單一階段（例如寫了 3 個都是測試方法），會被判定缺乏系統宏觀視野而扣分；必須均勻涵蓋開發、測試及運作各生命週期，並點出「去識別化」、「源碼檢測」、「稽核留存」等專業術語。

---

解題技巧

1. 結構層次分明：各子題以大標題、小標題與條列方式作答，第一眼即呈現出清晰的邏輯層次。
2. 量化與關鍵字化：說明 SLA 與資安指標時，使用業界與公部門標準術語，如 MTTR（平均修復時間）、RTO（復原時間目標）、SAST（靜態應用程式安全測試）、DAST（動態應用程式安全測試）、SSDLC。
3. 法規條款呼應：在答題文字中適度融入資通安全法規用語（如「委外審查」、「最小權限原則」、「測試資料去識別化」），展現公職資訊人員對實務法規的熟稔度。

---

【答案】

(一) 服務水準協議（SLA）在資訊系統服務與營運中扮演的角色及實例說明

1. SLA 在資訊系統服務與營運中扮演的角色：

• 確立服務品質與量化驗收標準： SLA 將抽象的「系統穩定」轉化為具體的量化指標（KPI / Metrics），明訂系統效能、可用性與回應時間，作為日常營運監控、勞務驗收及計費撥款的客觀依據。
• 明確劃分雙方權責與營運界限： 清晰界定委外廠商之維護範圍、支援服務時間（如 5x8 或 7x24）及機關自行的管理責任，避免系統發生異常時權責不清、互相推諉。

核心觀念

本題屬於軟體工程與系統分析中「軟體組態管理」（Software Configuration Management, SCM）的核心課題，主要考查**版本控制系統（Version Control System, VCS）**的基本原理、關鍵特性以及兩種主流架構：

1. 版本控制系統（VCS）的定義與價值：追蹤檔案隨時間演進的變更歷程、支援多工作業、維持系統基線（Baseline）一致性。
2. 集中式版本控制系統（Centralized VCS, CVCS）：以單一伺服器作為中央儲存庫（Central Repository），客戶端僅提取最新快照（Working Copy），所有提交與歷程查詢均需連線至中央節點。
3. 分散式版本控制系統（Distributed VCS, DVCS）：每個開發者客戶端皆為完整的儲存庫（Full Mirror Repository），包含完整的變更歷史紀錄，具備完全的離線作業能力與去中心化協同架構。

---

解題方法

1. 配分規劃與篇幅佈局：

• 第 (一) 小題配分 10 分，要求列出「三個重要特色並說明」，應採取「精準標題＋機制說明＋實務效益」三段式鋪陳，分點條列，確保閱卷委員能直接辨識關鍵字。
• 第 (二) 小題配分 20 分，為全題核心。應以對稱結構分別針對「集中式」與「分散式」進行論述，各涵蓋「架構運作原理」、「具體實例與操作機制」、「優缺點剖析」，並在最後附上「結構化綜合比較表」，展現統整與比較能力。

2. 切入視角：

• 結合軟體開發生命週期中的「協同合作」、「風險控管」與「追溯性」切入，強化答案的專業深度。

---

選項分析

本題為申論題型，無選擇題選項。答題關鍵在於架構完整度、術語精準度及論理邏輯。

---

解題技巧

1. 避免過度口語化：說明特色時，切忌只寫「可以看以前改了什麼」，應使用專有名詞如「變更歷程追溯（Historical Traceability）」、「狀態回滾（Rollback）」、「分支與合併（Branching & Merging）」。
2. 釐清分散式架構本質：許多考生容易誤以為「Git 一定沒有伺服器」，實務上 Git 多半會搭配 GitHub/GitLab 作為遠端主機。論述時必須點出：DVCS 中的遠端伺服器僅是「協同約定的集線中心（Hub）」，技術架構上本質仍是「對等節點（Peer-to-Peer）」，每個本地端都是完整資料庫。
3. 比較維度系統化：架構比較題宜從「資料儲存完整性」、「網路依賴度」、「單點故障風險（SPOF）」、「分支建立效能」與「權限控管難易度」等維度展開。

---

【答案】

(一) 版本控制系統（VCS）重要的三個特色

1. 版本歷程追蹤與狀態回溯（Version History & Rollback）

• 機制說明：系統會詳實記錄每次檔案變更的時間戳記、修改內容差異（Diff）、提交訊息（Commit Message）及提交者身分。
• 實務效益：當系統在新版本發現重大缺陷（Bug）或需求變更時，開發團隊能精準將特定檔案或整個專案還原至歷史上的任意穩定狀態（Baseline Rollback），大幅降低系統維護與除錯的風險。

2. 分支開發與智慧合併（Branching & Merging）

• 機制說明：系統允許開發者從主線（Main/Trunk）建立各自獨立的分支（Branch）以進行新功能開發或實驗性質修改，確保彼此程式碼互不干擾；開發完成後，透過合併（Merge）機制將變更整合成單一版本。
• 實務效益：支援多人平行開發，並能針對不同環境（開發、測試、正式上線）進行版本隔離，有效支撐持續整合（CI）流程。

3. 協同作業與衝突解決（Collaboration & Conflict Resolution）

• 機制說明：多位開發者同時修改同一份檔案時，系統能自動比對行號與內容差異，若修改區域不重疊則自動合併；若修改區域重疊，系統會標示出衝突區塊（Conflict Marker），由開發者進行人工仲裁與確認。

核心觀念

本題評量**敏捷軟體開發（Agile Software Development）**中「需求工程與使用者中心設計（User-Centered Design, UCD）」的核心收集與表達技術。命題重點在於釐清以下三種技術之定義、核心價值及其在需求分析生命週期中的互補關係：

1. 使用者故事（User Story）：敏捷開發中最基本的功能需求單位，以終端使用者視角出發，聚焦於「誰（Who）」、「要做什麼（What）」以及「能獲得什麼商業價值（Why）」，遵循 3C 原則（Card, Conversation, Confirmation）與 INVEST 準則。
2. 情境（Scenario）：對使用者在特定時空脈絡（Context）下為達成具體目標所經歷之連續事件與互動過程的敘事描述，著重於上下文背景、觸發事件、前置與後置條件，常與行為驅動開發（BDD）的 Given-When-Then 模式結合。
3. 故事板（Storyboard）：借鑑電影分鏡腳本概念的視覺化塑模技術，透過一系列連續的草圖、線框圖（Wireframes）或插圖，具象化呈現使用者在真實情境中操作系統的動態流程與人機互動體驗。

---

解題方法

本題為典型的申論名詞解釋與實務應用題，應採取「定義說明 $\rightarrow$ 核心特徵/標準結構 $\rightarrow$ 具體實例」的三段式結構依序作答：

1. 切入點與層次化論述：

• 先說明「使用者故事」是需求之骨架與價值核心（High-level abstraction）。
• 再說明「情境」是情節敘事與脈絡細節（Contextual narrative）。
• 最後說明「故事板」是人機介面與互動之視覺具象化（Visual representation）。

2. 實例設計原則：

• 三個實例應採用同一業務情境（例如：行動銀行或電子商務 App）串聯，以展現知識整合度，凸顯三者在同一個系統功能下如何層層細化，便於閱卷委員一目了然其差異。

---

解題技巧

1. 套用業界標準樣版提高專業度：

• 使用者故事務必寫出 Connextra 經典模板：身為 [角色]，我想要 [功能/目標]，以便於 [商業價值/好處]。
• 情境建議列出明確背景並套用 BDD 格式（Given-When-Then），強化可測試性。
• 故事板必須強調「畫面時序與使用者情境的連動」，以分鏡步驟（圖框說明）呈現。

2. 應考踩分關鍵字：

• User Story：3C 原則（Card, Conversation, Confirmation）、INVEST、驗收準則（Acceptance Criteria）。
• Scenario：背景脈絡（Context）、具體敘事（Concrete Narrative）、行為驅動開發（BDD）。
• Storyboard：視覺化（Visualization）、分鏡腳本、低保真原型（Low-fidelity Prototype）、使用者旅程。

3. 常見陷阱與扣分點：

• 誤將使用者故事寫成傳統瀑布式的條列規格書（缺乏使用者角色與價值）。
• 誤將情境（Scenario）寫成單純的系統內部演算法邏輯（缺乏使用者目標與環境背景）。
• 誤將故事板（Storyboard）等同於單一靜態 UI 介面圖（忽略其為「連續時序、包含使用者動態行為」的連環故事特性）。

---

【答案】

在敏捷開發（Agile Development）專案中，需求收集與溝通重視「價值導向」與「跨職能團隊共識」。針對 ABC 專案向團隊成員說明的內容如下：

一、使用者故事（User Story）

1. 定義與意涵： 使用者故事是從終端使用者或客戶的角度，用簡短、口語化的日常語言所撰寫的功能需求描述。其目的不是作為僵化的合約規格，而是作為促進利害關係人與開發團隊進一步溝通的媒介。
2. 核心架構與原則：

• 標準格式：

「身為一個〈角色/Persona〉，我想要〈進行某操作/功能〉，以便於〈達成商業目標/獲得價值〉。」

• 3C 原則：
• Card（卡片）：簡短記錄於實體便利貼或電子看板，避免過度設計。