111 高普考高考三級 資訊處理 系統專案管理 考古題詳解

核心觀念

本題評量大型資訊系統在進行「購買 vs. 自建」（Buy vs. Build）決策時，採用商用現成套件（COTS）之軟體架構設計與系統整合（System Integration）核心能力：

1. COTS（Commercial Off-The-Shelf）定義與本質：由第三方廠商開發並在市場上公開販售、租賃，非針對特定專案客製化開發之標準化軟體或硬體元件。
2. 軟體架構與系統設計考量（Design Considerations）：需求落差分析（Fit-Gap Analysis）、架構適應性、封裝/介面模式（Adapter / Wrapper Pattern）、非功能性需求（NFR，如安全性、效能、擴充性）及總體擁有成本（TCO）。
3. 系統整合（Integration）挑戰：黑箱（Black-box）特性、介面與協定不相容、膠水程式（Glue Code）負擔、廠商鎖定（Vendor Lock-in）、版本相依與演進不同步（Architectural Mismatch / Upgrade Drift）。

---

解題方法

本題為標準的「三段式申論題」，回答時應層次分明、對應題目三項子題：

1. 第一段：界定 COTS 範疇：精準給出定義，並對比「委外專案客製開發」與「自建開發」，點出其「現成取得」、「閉源黑箱」、「由廠商維護」等本質。
2. 第二段：系統設計面向（由內而外展開）：

• 業務需求層：落差分析與業務流程重組（BPR）。
• 軟體架構層：模組化耦合度、轉接器（Adapter）設計、資料庫與通訊標準介面。
• 系統品質層：安全性驗證、效能瓶頸預防、可用性。

3. 第三段：系統整合痛點（由技術到管理）：

• 技術層面：資料格式不符、黑箱除錯困難、膠水程式龐雜造成系統脆弱。
• 營運維護層面：版本升級相容性破壞、過度依賴廠商技術支援、廠商鎖定危機。

---

選項分析

本題為高考三級「系統專案管理」之申論題（非選擇題），無選項可供拆解。各子題命題重點與評分權重分析如下：

• 子題一：何謂 COTS（佔分約 20%~25%）：
• 核心要求：清楚寫出英文全名（Commercial Off-The-Shelf）、中文標準譯名（商用現成套件／商用現成軟體），並點出「非客製化」、「立即可用」、「第三方維護版權」之要素。
• 子題二：系統設計之考量因素（佔分約 35%~40%）：
• 核心要求：不可僅寫專案採購評估（如價格、合約），題目明確要求「系統設計上」，必須從「系統架構」、「介面規範」、「差異客製化限制」、「安全性與容錯設計」切入。
• 子題三：系統整合時可能發生之問題（佔分約 35%~40%）：
• 核心要求：著重在多個子系統對接與長期維運的現實困境，應點出軟體工程經典概念（如黑箱整合困難、Glue Code 過多、廠商鎖定、升級衝突）。

---

解題技巧

1. 破題關鍵專有名詞：適度加入軟體工程與系統整合專業術語，如 Fit-Gap Analysis（需求落差分析）、Adapter/Wrapper Pattern（轉接器模式）、Glue Code（膠水程式）、Vendor Lock-in（廠商鎖定）、Architectural Mismatch（架構不適配），能大幅提高閱卷給分。
2. 避開常見陷阱：

• 混淆 COTS 與 OSS（開源軟體）：COTS 通常具備商業版權、原始碼不公開（黑箱），不可將其假設為可任意檢視、編譯原始碼的開放原始碼專案。
• 答非所問（偏向專案採購）：第二子題問「系統設計」，應側重「技術架構與軟體工程面」，若篇幅全部寫供應商評選、合約談判或採購法，將被大幅扣分。

---

【答案】

一、COTS（Commercial Off-The-Shelf）之意涵

COTS（商用現成套件／現成商用軟體）係指由第三方商業供應商開發、銷售或租賃，供一般大眾或企業市場直接採購使用的標準化硬體或軟體產品。其主要特性包括：

核心觀念

本題出自民國 111 年公務人員高等考試三級考試（資訊處理類科）《系統專案管理》，旨在評量考生對現代雲端維運、敏捷專案管理以及 DevOps/SRE 現代工程實踐的掌握程度。

本題涉及的核心觀念與理論框架包含：

1. 網站可靠度工程（Site Reliability Engineering, SRE）之定義與核心原則：由 Google 工程副總裁 Ben Treynor 於 2003 年提出，其核心定義為「當你指派軟體工程師來設計與運作維運團隊時所發生的事（SRE is what happens when you ask a software engineer to design an operations team）」。核心實踐包含服務水準體系（SLI/SLO/SLA）、錯誤預算機制（Error Budget）、雜務管理（Toil Reduction）與不指責事後檢討（Blameless Postmortem）。
2. 量化可靠度公式：

• 服務水準指標（SLI）：度量服務表現的量化指標。
• 服務水準目標（SLO）：由業務與工程團隊共同訂定的目標合規比率。
• 錯誤預算（Error Budget）：允許系統不可用或出錯的配額上限，其關係式為： $\text{Error Budget} = 1 - \text{SLO}$

3. SRE 與軟體工程（Software Engineering, SE）的關係：SRE 是軟體工程理念在系統維運領域的延伸與特化。本質原則為「將維運視為軟體工程問題（Treat Operations as a Software Problem）」，強調透過程式碼、架構設計與自動化取代傳統手動操作。
4. SRE 與 DevOps 的關係與差異：業界權威觀點（Google）總結為「class SRE implements DevOps」，即 DevOps 屬於文化、理念與組織哲學層次，而 SRE 則是將 DevOps 理念具體落地與落實的一套工程實務與規範。

---

解題方法

本題為標準的觀念申論題，在國家考試評分架構下，應採取「分項破題、脈絡對比、圖表整合」的三段式結構作答：

1. 第一部分：解析 SRE 的本質與運作機制

• 先提出 SRE 的權威定義（Google / Ben Treynor 原則）。
• 深入闡述 SRE 維繫系統可靠度的兩大支柱：量化指標體系（SLI、SLO、Error Budget）與工程化維運（Toil 限制 $\le 50\%$、自動化替代人工作業）。

2. 第二部分：申論 SRE 與軟體工程（SE）之關係

• 從「技能重疊性」、「思維模式」及「產出成果」三個切入點切入。
• 明確指出 SRE 團隊由具備軟體工程背景的人員組成，其工作成果為具備高可用架構的軟體基礎設施（Infrastructure as Code）與自動化工具，而非僅是手動執行伺服器維護。

3. 第三部分：深入比較 SRE 與 DevOps 之異同

• 採取物件導向概念引出兩者本質關係（DevOps 是 Interface/哲學，SRE 是 Concrete Implementation/實作）。
• 建立系統化比較表，從「層級定位」、「職能角色」、「風險與變更控制」、「核心衡量指標」及「雜務處理方式」等多維度清晰對比，讓閱卷委員能一目了然給予滿分評級。

---

選項分析

本題為高等考試三級申論題，非選擇題，故無個別選項；各子題在閱卷評分時的核心給分重點與採分點分析如下：

1. 子題一：SRE 之定義（建議配分：8～10 分）

• 採分關鍵：能否明確寫出「以軟體工程方法解決維運問題」的核心理念；是否帶出 SLI、SLO、SLA、錯誤預算（Error Budget）及減少雜務（Toil）等代表性機制。若僅將 SRE 描述為「負責網站不當機的工程師」，未觸及工程化與預算控制概念，僅能獲得基礎分。

2. 子題二：SRE 與軟體工程之關係（建議配分：6～8 分）

• 採分關鍵：能否準確界定「延伸與特化」關係。軟體工程專注於功能開發、生命週期管理與架構設計；SRE 則將這些軟體工程技術（如寫程式、版本控制、單元測試、重構）套用在生產環境的非功能性需求（穩定度、擴充性、容錯性）之上。

3. 子題三：SRE 與 DevOps 之差異（建議配分：8～10 分）

• 採分關鍵：切忌將兩者答成「相互競爭」或「互斥」，必須精準指出兩者是「理念與實踐」的共生關係（class SRE implements DevOps）。若能利用維度比較表清楚呈現「文化 vs. 規範」、「抽象目標 vs. 具體指標（如 Error Budget）」，即可拿下該子題頂標分數。

---

解題技巧

1. 經典金句直擊核心： 在卷面開頭直接寫出 Google 的經典公式：「class SRE implements DevOps」與「Treat Operations as a Software Problem」，向閱卷委員展現扎實的專業底蘊。
2. 善用指標三部曲與數學定義： 說明 SRE 時，務必完整交代 $\text{SLI} \to \text{SLO} \to \text{Error Budget}$ 的連鎖管理邏輯。將可靠度與創新速度的拉鋸具象化為「錯誤預算歸零時暫停新功能發布」，是專案管理實務高分關鍵。
3. 避免常見扣分陷阱：

• 陷阱一：把 SRE 誤認為「傳統系統管理員（System Administrator, SysAdmin）換個好聽的職稱」。必須強調 SRE 的工作時間通常被嚴格規定至少有 $50\%$ 以上投注於「軟體研發與自動化專案」，傳統維運雜務（Toil）上限為 $50\%$。
• 陷阱二：將 DevOps 與 SRE 二分對立。

核心觀念

本題評量軟體專案估算中經典的經驗演算法成本模型（Algorithmic Cost Estimation Models），重點在於兩代模型的演進脈絡與架構差異：

1. COCOMO（COCOMO 81）的核心限制：

• 以傳統「瀑布式生命週期（Waterfall Model）」與「由零開始撰寫自訂程式碼」為假設前提。
• 規模僅以程式碼行數（KDSI, Kilo Delivered Source Instructions）為單一度量。
• 專案模式固定分為組織型（Organic）、半獨立型（Semi-detached）、嵌入型（Embedded）三種，其規模不經濟指數為不可變的常數。

2. COCOMO II 的現代化改良：

• 支援反覆式開發（Iterative）、螺旋模型（Spiral）、敏捷雛型與物件導向、商用現成套件（COTS）及軟體重用（Software Reuse）。
• 規模度量多元化：導入物件點（Object Points / Application Points）、功能點（Function Points, FP）及原始程式碼行數（SLOC）。
• 以動態的 5 項「規模因子（Scale Factors, $SF$）」取代固定的三種開發模式，計算規模指數 $E$： $E = B + 0.01 \times \sum_{i=1}^{5} SF_i$

3. COCOMO II 的三階段子模型（Sub-models）：

• 依專案生命週期中「資訊掌握的細緻程度」由粗到細分為：應用程式合成模型（Application Composition Model）、早期設計模型（Early Design Model）、後架構模型（Post-Architecture Model）。

---

解題方法

本題為高普考常見的「比較與說明型」申論題，採雙核心架構展開作答：

1. 第一部分（差異性）：從「開發典範與生命週期」、「規模度量指標」、「規模經濟指數計算」、「成本驅動因子與校準」、「重用與 COTS 支援」等 5 大構面進行對比，並搭配綜合比較表，方便閱卷委員快速辨識得分關鍵字。
2. 第二部分（COCOMO II 子模型與用途）：針對三大子模型，逐一明確交代其「適用時機與生命週期階段」、「規模衡量單位與驅動因子機制」、「在系統開發與專案管理上的具體用途」，層次分明。

---

解題技巧

1. 避免概念混淆：

• 勿將 COCOMO 81 的「三種層級（Basic、Intermediate、Detailed）」與 COCOMO II 的「三大子模型（Application Composition、Early Design、Post-Architecture）」混為一談。
• 勿將 COCOMO 81 的「三種開發模式（Organic、Semi-detached、Embedded）」誤寫入 COCOMO II（COCOMO II 已改用 5 項 Scale Factors 計算指數）。

2. 答題結構化：名詞均附上英文全稱或標準簡寫（如 SLOC、FP、NOP、COTS），並以小標號列點作答，呈現資訊處理專業人員的邏輯架構。

---

【答案】

一、COCOMO 與 COCOMO II 之間之差異性

Barry W. Boehm 分別於 1981 年與 2000 年提出 COCOMO（亦稱 COCOMO 81）與 COCOMO II。兩者之主要差異如下：

1. 支援之軟體生命週期與開發典範不同：

• COCOMO：建立於傳統線性瀑布模型假說，預設軟體均由零開始循序開發。
• COCOMO II：支援現代快速原型（Prototyping）、螺旋模型、物件導向、元件化開發、反覆增量開發以及 COTS（商用現成軟體）整合。

2. 軟體規模度量指標（Size Metric）之多樣性：

• COCOMO：僅使用單一維度的原始程式碼行數（KDSI，千行交付原始碼指令）。
• COCOMO II：依專案成熟度提供多種度量標準，包括物件點（Object Points / Application Points）、未調整功能點（Unadjusted Function Points, UFP）與原始碼行數（KSLOC）。

3. 規模指數（Scale Factor）決定方式不同：

• COCOMO：將專案僵化歸類為組織型（Organic, 指數 1.05）、半獨立型（Semi-detached, 指數 1.12）、嵌入型（Embedded, 指數 1.20），規模不經濟指數為固定值。
• COCOMO II：打破三種固定模式，採用 5 項規模因子（前例性 PREC、開發彈性 FLEX、架構與風險處理解決 RESL、團隊凝聚力 TEAM、製程成熟度 PMAT）動態評定規模指數 $E$。

4. 成本驅動因子（Cost Drivers / Effort Multipliers）之調整：

• COCOMO：在中階與高階模型中採用固定 15 個成本驅動因子。
• COCOMO II：因應現代運算環境（如分散式、虛擬化、高可靠度工具），精簡整合為 7 個（早期設計）與 17 個（後架構）成本驅動因子，並納入開發者異動率、多據點開發（Site）等現實專案考量。

核心觀念

本題評量大型資訊系統中「敏捷擴展」（Scaling Agile）之理論架構、治理機制與實務落地評估，核心概念包括：

1. 敏捷方法擴展（Scaling Agile）：傳統 Scrum 或極限編程（XP）設計主要針對單一跨職能團隊（約 5～9 人）。當面臨跨數十人至數百人的大型系統時，必須解決「多團隊協同」、「複雜相依性（Dependency）」與「組織戰略對齊」問題，常見框架包含大規模敏捷框架（Scaled Agile Framework, SAFe）、大規模 Scrum（Large-Scale Scrum, LeSS）及 Scrum of Scrums（SoS）。
2. 擴展觀點（Perspectives）：需從「組織與團隊結構」、「系統架構與工程實踐」、「策略治理與價值流」三大維度審視。
3. 實務可行性分析（Feasibility Analysis）：依循專案管理之可行性評估維度，從「組織與文化可行性」、「架構與技術可行性」、「流程與協同可行性」、「資源與成本可行性」進行實務面評估與風險因應。

---

解題方法

本題為高考三級《系統專案管理》之典型「架構評析與情境實務題」，解題應採取兩階段結構化剖析：

1. 第一階段（觀點說明）：界定小型敏捷與大型敏捷本質上的差異。不可僅泛談敏捷宣言，應具體提出組織協同、架構演進與價值治理三大觀點，並援引業界標準實踐（如 SAFe 之 Release Train、PI 規劃會、Scrum of Scrums）。
2. 第二階段（可行性分析）：針對 A 公司由「小型專案」邁向「大型系統」的轉型情境，從實務操作面（非僅理論）剖析可行性。指出痛點（如遺留架構耦合、相依性地獄、管理心態抗拒），並針對各維度給予客觀可行性結論與對策。

---

選項分析

本題為申論問答題，各子題評分焦點與架構分析如下：

• 子題一：擴展敏捷方法之觀點（Perspective）：
• 組織與團隊觀點：核心在於多團隊的並行運作與階層解構，需從單一團隊自治轉變為「團隊群（Team of Teams）」協同。
• 架構與工程觀點：大型系統無法承受頻繁架構混亂，須兼顧「湧現式設計（Emergent Design）」與「意圖性架構（Intentional Architecture）」，並依賴高成熟度的 DevOps 與微服務解耦。
• 策略與治理觀點：需建立跨專案的價值流（Value Stream）對齊機制，確保各多團隊的 Backlog 與企業願景（Portfolio Epics）保持一致。
• 子題二：實務面可行性分析與討論（Feasibility）：
• 組織與文化層面：A 公司既有小型敏捷經驗是優勢，但大型專案涉及跨部門利益與中階主管權限轉移，文化阻力高。
• 技術與架構層面：大型系統若未進行模組化或微服務化，頻繁整合與部署具高度技術風險。
• 流程與協同層面：相依性管理為成敗關鍵，若缺乏固定節奏的同步機制，容易退化為失控的混亂。
• 整體可行性判定：具備條件可行性（Conditionally Feasible），不建議「大爆炸式（Big Bang）」一次性替換，應採取「漸進式擴展」或「混合模式（Hybrid/Water-Scrum-Fall）」。

---

解題技巧

1. 破除單一專案思維：作答時切忌通篇只寫 Daily Standup、Sprint Review 等單一團隊操作，必須展現出「跨團隊協調」與「組織級別」的管理視野（如敏捷發布火車 ART、計畫增量 PI Planning、產品負責人同步會 PO Sync）。
2. 實務分析務求具體：論述可行性時，必須對比「小型系統」與「大型系統」的技術與管理落差（如架構耦合度、CI/CD 吞吐量、利益關係人複雜度），切忌空談口號。
3. 結論明確務實：公職考試重視可落地性，提出評估結論時應輔以具體推動路徑（如 Pilot 專案試行、微服務解耦、敏捷卓越中心 CoE 建立），展現全方位專案規劃深度。

---

【答案】

一、擴展敏捷方法（Scaling Agile）之核心觀點（Perspective）

當企業從單一小型系統走向大型系統時，擴展敏捷不再只是開發方法的替換，而是企業級專案協同與交付模式的轉型。主要包含以下三大核心觀點：

1. 組織架構與多團隊協同觀點（Organization & Coordination Perspective）

• 團隊群協同（Team of Teams）：大型系統動輒需要數十至數百人參與開發，單一 Scrum 團隊無法負擔。擴展敏捷主張建立「網絡型跨職能團隊架構」，透過 Scrum of Scrums (SoS) 或 SAFe 之 敏捷發布火車（Agile Release Train, ART），將多個相互依賴的敏捷團隊組織在共同的業務目標下。
• 角色層級擴展：傳統敏捷的單一 Product Owner (PO) 與 Scrum Master (SM) 角色不足以應對大型系統，需向上擴展設立「產品管理（Product Management）」統籌全域願景，以及「發布火車工程師（Release Train Engineer, RTE）」協調全域流程阻礙。

2. 系統架構與工程實踐觀點（Architecture & Engineering Perspective）