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

核心觀念

本題測驗需求工程（Requirements Engineering）中「非功能需求」（Non-Functional Requirements, NFRs）的定義、分類架構及其在特定垂直領域（智慧司法／科技法庭）之實務應用。

1. 非功能需求定義：依據國際軟體工程標準 ISO/IEC 25010 系統與軟體品質模型，功能需求（Functional Requirements）定義系統「做什麼」（What the system does），非功能需求則定義系統「如何展現品質與遵循限制」（How well the system performs），包含效能效率、相容性、易用性、可靠性、安全性、可維護性及可攜性等品質屬性（Quality Attributes）。
2. 科技法庭（Tech Courtroom）之領域限制：科技法庭涉及訴訟程序之正當法律程序（Due Process of Law）、公開審判原則、證人保護及數位證據保全。系統若發生中斷、延遲、竄改或個資洩漏，將直接侵害當事人訴訟權益，甚至造成審判程序違法。因此其非功能需求之嚴謹度遠高於一般商用資訊系統。

---

解題方法

1. 分析架構選取：採用 ISO/IEC 25010 品質模型作為理論基礎，自八大品質屬性中挑選最契合「法庭開庭審理情境」的 4 個核心維度：

• 可用性／可靠性（Availability & Reliability）：保障庭訊持續進行不中斷。
• 安全性／完整性（Security & Integrity）：確保數位證據真實性與保護隱私。
• 效能／即時性（Performance & Responsiveness）：維持詰問攻防與卷證呈現之流暢。
• 易用性（Usability）：確保非資訊專業之司法人員與訴訟當事人能直覺操作。

2. 實例鋪陳原則：非功能需求不可僅給予抽象概念，每個項目必須給出量化指標（SLA/SLO）​並緊扣法庭實務作業情境（如交互詰問、證人去識別化、電子卷證開示、即時筆錄投影）。

---

選項分析

本題為申論題（非選擇題），無各別選項可供逐一正誤分析。評分與答題關鍵在於：

• 切忌通用空洞：若僅寫「系統速度要快、系統要安全」等未結合法庭情境之通用詞彙，得分通常僅在及格邊緣。
• 結合司法實務：必須切中司法特考檢察事務官電子資訊組的考選宗旨，凸顯資通訊技術（ICT）在刑事訴訟與法庭攻防上的實務落地應用。

---

解題技巧

1. 品質維度速記口訣：「安、可、效、易」（安全性、可用性、效能性、易用性），此為各類資訊系統申論題最穩健且涵蓋面最廣的四角架構。
2. 量化數據（Metrics）提升專業度：在舉例時主動寫出量化指標（例如：可用度 $99.99\%$、還原時間目標 $\text{RTO} \le 30$ 秒、網路傳輸延遲 $< 500\text{ ms}$、加密標準 $\text{AES-256}$），能向閱卷委員展現系統架構規劃的實務能力。
3. 對照法律規範彰顯跨域能力：舉例時融入刑事訴訟法證人保護（變聲遮蔽）、公訴卷證開示等情境，切合檢察事務官職職能特性。

---

【答案】

科技法庭旨在透過資訊科技輔助審理，達成審判程序公開、透明與流暢之目標。針對此系統，4 個極為重要的非功能需求及其具體實例如下：

核心觀念

本題測驗「系統實作與轉換（System Implementation and Conversion）」階段的核心決策能力。在新系統開發完成並通過驗收測試後，如何將日常作業由舊系統過渡至新系統，稱為「系統轉換」（System Conversion 或 Cutover）。轉換決策本質上是專案管理三重限制（Triple Constraint）在系統上線期的權衡，主要評估維度包括：

1. 風險（Risk）：新系統故障時對組織營運衝擊的容忍程度。
2. 成本（Cost）：轉換過程耗費的人力、硬體、資料同步與維護雙軌運作之費用。
3. 時間（Time）：完成整體轉換作業所需的歷時長短與停機維護窗口。
4. 組織承受度（Impact Scope）：使用者對操作變革與業務流程變動的適應彈性。

---

解題方法

本題為國家考試標準的「定義＋比較」型申論題，答題策略應採取「結構化矩陣解題法」：

1. 策略定義與運作機制：精確列出資訊管理與軟體工程公認的四種標準轉換策略，定義其運作原理與實務適用情境。
2. 維度化比較分析：針對題目指定的「風險、時間、成本」，輔以「主要優缺點」，繪製完整的橫向對比表格，使閱卷委員一目了然。
3. 維度量化／定性評級：各策略在風險、時間、成本的維度上，必須給予明確的定性評等（高／中／低），並闡明成因。

---

選項分析（申論題轉換策略決策分析）

本題為申論題型，轉換決策中的四種策略各為組織評估時的替代選項（Alternatives），其決策取向分析如下：

• 選項一：直接轉換（Direct Conversion）
• 決策特性：高風險、低成本、極短轉換時間。
• 可行性評估：僅適用於系統具備完備資料備份、容錯能力高、新舊系統不相容無法並行，或失敗代價極低之次要系統；核心任務系統（Mission-Critical System）嚴禁輕易採用。
• 選項二：平行轉換（Parallel Conversion）
• 決策特性：極低風險、極高成本、時間長。
• 可行性評估：適用於高可靠度要求的金融帳務、醫療生命維持或司法檢調核心卷證系統；需有充足預算與人力負擔雙重工作量。
• 選項三：領航轉換（Pilot Conversion）
• 決策特性：局部承擔風險、成本適中、推展時程受限於分區推進。
• 可行性評估：以「組織單位／地理位置」為切割基準，適用於具多個分支機構（如各地檢署、分行、連鎖門市）的架構。
• 選項四：階段轉換（Phased Conversion）
• 決策特性：風險依模組分散、成本中高、整體建置週期最長。
• 可行性評估：以「功能模組」為切割基準，適用於模組化程度高、功能龐大且各子模組耦合度低（Low Coupling）的大型 ERP 或整合型資訊系統。

---

解題技巧

1. 記憶口訣：「直、平、領、階」（直接、平行、領航、階段）。
2. 易混淆陷阱辨析：

• 領航轉換 vs. 階段轉換：
• 領航轉換（Pilot）：完整功能在局部單位／分行試行（Full functionality at a single site）。
• 階段轉換（Phased）：局部功能在全體單位導入（Incremental functionality across all sites）。

3. 風險與成本的反比規律：

• 轉換風險與執行成本通常呈反比：$\text{Risk} \propto \frac{1}{\text{Cost}}$
• 直接轉換成本最低但風險最高；平行轉換成本最高但風險最低。此規律可用於快速驗算答題邏輯是否自相矛盾。

---

【答案】

一、四種重要系統轉換策略詳細說明

1. 直接轉換（Direct Conversion / Plunge / Cold Turkey）

• 定義與運作機制：在預定的切換時間點（通常選在週末或營運離峰時段），完全停用舊系統，同時立即啟動新系統並承接所有日常業務作業。又稱為「斷崖式切換」或「Big Bang」。
• 適用情境：新舊系統架構差異過大而無法並存、硬體資源極度匱乏無法支撐雙軌運作，或是新系統非關鍵核心、失敗時容許停機回滾（Rollback）之情境。

核心觀念

本題評量軟體工程中「軟體專案估算（Software Project Estimation）」的核心流程與度量技術，涵蓋以下關鍵定義與公式：

1. 三階段推估鏈架構（Estimation Pipeline）： 軟體估算的標準推導路徑為「系統規模（Size） $\rightarrow$ 開發工作量（Effort） $\rightarrow$ 開發工期與人力（Schedule & Staffing）」。
2. 演算法成本估算模型（Algorithmic Cost Models）： 以產業界與國家考試最常採用的 COCOMO II（Constructive Cost Model II）為代表，其核心公式為：

• 工作量（Effort，以人月 PM 為單位）： $Effort = A \times (Size)^B \times \prod_{i=1}^{n} EM_i$ 其中 $A$ 為校準常數，$B$ 為規模不經濟指數（Scale Factor），$EM_i$ 為工作量乘數（Effort Multipliers，如人員能力、環境複雜度）。
• 開發時程（Duration / Schedule，以月或天為單位）： $TDEV = C \times (Effort)^D$ 其中 $C$ 與 $D$ 為經驗常數，$TDEV$（Time to Develop）可進一步換算為工作天數（例如 $1\text{ 人月} \approx 20 \sim 22\text{ 工作天}$）。
• 所需人力（Average Staffing）： $Staff = \frac{Effort}{TDEV}$

3. 布魯克斯法則（Brooks' Law）與溝通成本： 開發人力並非越多越好，專案成員之間的溝通管道數為 $\frac{n(n-1)}{2}$。向落後的專案增加人力只會使專案更加落後。
4. 功能點分析（Function Point Analysis, FPA）： 由 Allan Albrecht 提出，現為 IFPUG（國際功能點推廣協會）標準。透過五大資訊功能元件與 14 項一般系統特性（General System Characteristics, GSC），以「使用者外部可見功能」獨立衡量系統大小，其計算式為： $FP = UFP \times VAF$ $VAF = 0.65 + 0.01 \times \sum_{i=1}^{14} C_i$

---

解題方法

本題為標準的兩段式申論題：前半段須交代「大小、天數、人力」的系統化推估流程；後半段須選定一種最具代表性的專案大小估算方法（推薦採用標準規範最嚴謹的「功能點分析法, FPA」），詳細說明其理論、操作與優缺點。

第一部分：系統分析師估計專案大小、工作天數與人力的推估程序

系統分析師應遵循結構化量化流程進行推估，步驟如下：

1. 步驟一：估計開發專案的大小（Software Size）

• 功能導向法（Function-Oriented）：在需求分析初期採用功能點分析法（FPA），從使用者觀點計算未調整功能點（UFP）與調整後功能點（FP）。
• 程式碼行數法（Size-Oriented）：透過歷史經驗或功能分解，結合三點估計法（PERT：期望值 $S_e = \frac{a + 4m + b}{6}$）推估潛在的原始碼行數（KLOC）。
• 物件/使用案例導向法：若採用物件導向分析（OOAD），可計算使用案例點（Use Case Points, UCP）或敏捷開發中的故事點（Story Points）。

2. 步驟二：推估所需工作量（Effort）

• 透過基準生產力率（Productivity Rate）換算： $Effort = \frac{Size}{\text{生產力（如 } LOC/\text{人月 或 } FP/\text{人月）}}$
• 或代入演算法模型（如 COCOMO II）： $PM = A \times (Size)^B \times \prod EM_i$ 此處計算出完成該專案所需的總工作量（人月，Person-Months）。

3. 步驟三：估計開發時程與工作天數（Schedule / Duration）

• 依據 COCOMO II 之時程公式計算最短合理開發月數： $TDEV = C \times (PM)^D$
• 將開發月數轉換為工作天數： $\text{工作天數} = TDEV \times 21.75\text{ 天（每月平均法定工作天）}$
• 時程不可無限制壓縮，存在「不可壓縮時程極限（Impossible Square Region）」。

4. 步驟四：配置所需人力（Staffing）

• 計算平均全職人力（Full-Time Equivalent, FTE）： $\text{平均團隊人數 } N = \frac{Effort (PM)}{TDEV (\text{月})}$
• 結合瑞利曲線（Rayleigh-Norden Curve）繪製人力動態分佈圖，掌握需求分析、系統設計、編碼測試至部署驗收各階段的人力波動，而非採齊頭式固定人力配置。

---

第二部分：專案大小估計方法——功能點分析法（Function Point Analysis, FPA）

1. 理論基礎

• 使用者視角獨立性：傳統 LOC（程式碼行數）會因程式語言不同（高階語言行數少、低階語言行數多）、工程師程式風格差異而失真。FPA 奠基於「系統為使用者提供何種功能與資料服務」，完全獨立於程式語言、技術架構與實作工具。
• 早期度量能力：FPA 在軟體生命週期的「需求規格確立（SRS）」階段即可進行評估，不需等到系統編碼完成，符合專案早期估算的實務需要。

2. 操作方式

FPA 的標準執行程序分為四個關鍵步驟：

• 步驟 (1)：識別並計算五大功能元件（Information Domain Values） 將系統功能歸類為以下五類元件，並依其參照檔案數（FR/FTR）與資料元素類型數（DET）評定複雜度（低、中、高）：

1. 內部邏輯檔案（Internal Logical Files, ILF）：由本系統維護與儲存的使用者可識別資料群組。
2. 外部介面檔案（External Interface Files, EIF）：僅供本系統讀取引用、由其他外部系統維護的資料群組。
3. 外部輸入（External Inputs, EI）：由外部傳入系統，且會新增、修改、刪除內部資料的交易程序（如：表單送出）。
4. 外部輸出（External Outputs, EO）：系統處理後傳給外部的資訊，涉及衍生計算或統計呈現（如：產出報表）。
5. 外部查詢（External Inquiries, EQ）：自系統檢索並直接呈現資料，不包含複雜演算法或狀態變更的交易程序（如：條件查詢）。

• 步驟 (2)：計算未調整功能點（Unadjusted Function Points, UFP） 依據標準複雜度矩陣將各元件個數乘上對應權重後加總：

核心觀念

本題測驗雲端運算（Cloud Computing）之基礎架構與服務架構，核心理論依循美國國家標準暨技術研究院（NIST SP 800-145）所發布之雲端運算標準定義：

1. 雲端部署模型（Deployment Models）：探討運算基礎架構的擁有權、所在位置（地端或代管中心）以及存取權限範圍，包含公有雲（Public Cloud）、私有雲（Private Cloud）、混合雲（Hybrid Cloud）。
2. 雲端服務模型（Service Models）與責任共擔模型（Shared Responsibility Model）：探討雲端服務供應商（Cloud Service Provider, CSP）依據運算堆疊（Stack）抽象化程度不同所提供的三大主流服務層次（SPI 模型：IaaS、PaaS、SaaS），以及客戶與供應商之間在網路、硬體、作業系統、中介軟體、資料與應用程式的管理分工邊界。

---

解題方法

1. 第（一）小題（部署模型，15 分）：

• 採「定義 $\to$ 核心特性 $\to$ 適用情境」三維度分別拆解公有雲、私有雲與混合雲。
• 點出關鍵專有名詞：多租戶（Multi-tenancy）、單租戶（Single-tenant）、資源池化（Resource Pooling）、隨選即用／計量付費（Pay-as-you-go）、雲端爆量（Cloud Bursting）。
• 輔以三者在「安全性、掌控度、建置成本、維運複雜度」之綜合比較表，強化作答的結構性與對比性。

2. 第（二）小題（服務供應商之服務方式，15 分）：

• 以 NIST 標準「SPI 模型」切入，循序論述 IaaS、PaaS、SaaS 三種不同層次的服務供應商模式。
• 剖析各層級之「供應商交付內容」、「客戶自主管理範圍」與「業界具體實例」（如 AWS、Microsoft Azure、GCP、Salesforce）。
• 加入「責任共擔模型架構表」，具體標示從實體硬體到頂層應用程式的控管邊界，突顯電子資訊組考生的系統工程素養。
• 酌情補充現代無伺服器架構（FaaS / Serverless）或 XaaS（Everything as a Service），展現答題深度。

---

選項分析

本題為申論題，非選擇題，無選項分析。

---

解題技巧

1. 標準化引用立論基礎：開篇提及 NIST SP 800-145，能向閱卷委員展現正規且具權威性的理論基礎，避免流於口語化或非專業雜誌的粗淺描繪。
2. 善用「堆疊分層表」呈現責任邊界：在回答第（二）小題時，條列式說明各服務模式後，務必附上 IT 堆疊矩陣表（包含：應用程式、資料、執行時期、中介軟體、作業系統、虛擬化、伺服器、儲存設備、網路），標示何者為「客戶自行管理」、何者為「供應商託管」，此為高分評分指標。
3. 避免常見盲區：

• 勿將「混合雲」單純寫成「同時向兩家公有雲業者租用服務」（此為多雲架構 Multi-cloud）。混合雲之本質在於「私有雲與公有雲環境間具備可攜性、協同性與整合技術（如 API、VPN 連線、資料同步機制）」。
• 清楚區分部署模型（公/私/混合）與服務模式（IaaS/PaaS/SaaS），兩者為正交維度，切勿混為一談。

---

【答案】

（一）公有雲、私有雲、混合雲之定義與說明

依據美國國家標準暨技術研究院（NIST SP 800-145）之規範，雲端部署模型依基礎設施之所有權、存取權限與建置架構，說明如下：

1. 公有雲（Public Cloud）

• 定義：由第三方雲端服務供應商（如 AWS、Microsoft Azure、Google Cloud Platform 等）所擁有與運營，其雲端基礎設施透過網際網路（Internet）開放給一般大眾或大型產業組織共享租用。
• 核心特性：
• 多租戶架構（Multi-tenancy）：多個租戶共享底層實體硬體與網路資源，透過邏輯虛擬化技術進行安全隔離。
• 低初始成本與計量付費：企業免去自建機房與購置高額伺服器的資本支出（CAPEX），轉為依實際資源使用量付費的營運支出（OPEX）。
• 高彈性與高擴展性（Elasticity & Scalability）：具備近乎無限之運算與儲存池，可依系統流量動態調整資源配置。
• 適用情境：新創事業、不可預測突發流量之系統、一般非機密性業務應用，或需快速敏捷開發驗證的概念性驗證（PoC）專案。

2. 私有雲（Private Cloud）

• 定義：指專門為單一企業或組織建置並專屬使用的雲端基礎設施。可建置於企業內部自有資料中心（On-Premises），亦可委託第三方機房代管（Hosted Private Cloud）。
• 核心特性：
• 單租戶架構（Single-tenant）：底層實體硬體完全獨立專用，資源不與外界或其他租戶共享。
• 高度安全性與資料主權：企業可自主定義最高規格的資安防護政策、加密機制與存取控制，能完全掌控資料實體存放位置以符合法律規章（如個人資料保護法、金融法規等）。
• 高建置成本與維運負擔：硬體建置成本極高，且組織需自行組建專業維運團隊負責軟硬體生命週期管理。
• 適用情境：政府國防單位、金融監理核心系統、醫療病歷資料庫，以及對延遲極度敏感或有嚴苛法遵合規要求之關鍵任務系統。

3. 混合雲（Hybrid Cloud）

• 定義：結合至少一種私有雲與至少一種公有雲環境，透過標準化或專屬技術（如專用線路 Direct Connect、VPN、API 介接、容器編排技術 Kubernetes）將兩者緊密綁定，達成資料傳輸與應用程式相互流通與協同運作之整合架構。
• 核心特性：
• 兼顧資安與彈性：核心敏感資料保留於私有雲地端，非機密或對外服務則利用公有雲的大規模運算能力。
• 雲端爆量（Cloud Bursting）：平時以地端私有雲運算為主；逢尖峰時段運算容量不足時，系統自動將超載負載引導擴展至公有雲執行，負載消退後再縮回，最佳化總體擁有成本（TCO）。
• 架構複雜度高：網路連線安全、地端與雲端資料同步、身分存取控管（IAM）以及跨平台統一監控維運之門檻顯著提高。