109 高普考高考二級 資訊處理 軟體專案管理研究 考古題詳解

核心觀念

本題評量軟體專案管理中「專案資源管理」（Project Resource Management）與「專案溝通管理」（Project Communication Management）的整合應用，涉及組織行為與團隊動態理論。關鍵觀念與理論架構包含：

1. 角色與責任定義工具：

• 責任指派矩陣（RAM, Responsibility Assignment Matrix）與 RACI 矩陣：定義每一工作封裝（Work Package）中各成員的角色：負責者（Responsible）、當責者（Accountable，僅能有一人）、諮詢者（Consulted）、告知者（Informed）。

2. 溝通管道容量公式（Communication Channels）： $C = \frac{n(n - 1)}{2}$ 其中 $n$ 代表專案團隊成員人數。通訊路徑隨團隊人數呈平方級數（$O(n^2)$）急遽增長。
3. 布魯克斯法則（Brooks' Law）： 「為進度落後的軟體專案增加人手，只會使進度更加落後。」（Adding manpower to a late software project makes it later.）指出新進人員的訓練成本與溝通開銷會抵銷甚至反噬產能。
4. 軟體工程品質與組織原則：

• 職責分離原則（Separation of Duties）：開發與測試、稽核需相互獨立以防範盲點。
• 社會惰化（Social Loafing / 三個和尚效應） 與 角色模糊（Role Ambiguity）。

---

解題方法

本題為典型的分析型申論題。解題切入點應針對題目情境（跨部門、背景相異、初期職責不清、人手配置失衡）建立結構化分析架構：

1. 問題成因分析：點出成員認知落差與管理階層指派偏頗的根本成因。
2. 四面向核心剖析：嚴格對應題目要求的「角色分類」、「溝通量」、「角色重疊」與「角色減化」，分別論述其在專案生命週期中的現象、負面衝擊及控制手段。
3. 管理對策整合：導入國際標準專案管理工具（如 RACI、WBS、敏捷跨功能團隊機制）提出具體治理方案。

---

選項分析

本題為高普考高考二級之「申論題」，非選擇題型，故無選項可供逐一判別。評分關鍵在於能否精準解析題目指定之四項核心議題，並提出具實務深度的解決策略。

---

解題技巧

1. 理論與公式點綴：在討論「溝通量」時務必列出 $C = \frac{n(n - 1)}{2}$ 並引用「布魯克斯法則」，這是一等高考試卷的關鍵得分指標。
2. 避免空泛陳述：不可僅寫「要多溝通」、「要劃分責任」，須具體列出專案管理專業工具（如 RACI 表、WBS 字典、職責矩陣、每日立會、雙人配對）。
3. 正反兩面論述：分析「角色重疊」與「角色減化」時，除了點出缺失（責任推諉、測試盲點），亦可補充其在特定情境下的正向價值（如備援機制、全端敏捷開發），展現高考二級研究人員應有的思維廣度。

---

【答案】

一、前言與情境剖析

軟體專案具備高度知識密集與高變動性特質。當成員來自不同部門、具備不同專業背景且初期權責不明時，極易引發「認知落差」；而管理階層盲目指派更常導致資源配置失衡（人員過多或人手不足）。以下就專案執行過程中所衍生的四項關鍵問題進行深入研析：

---

二、核心議題研析

（一）角色分類（Role Classification）問題

1. 現象與挑戰：

• 軟體生命週期包含分析、設計、編程、測試、部署與維運。若僅以傳統行政職稱（如專員、組長）進行粗略指派，無法反映軟體專業分工（如系統分析師 SA、架構師 SD、程式開發者 PG、品質保證 QA、維運工程師 DevOps、產品負責人 PO）。
• 成員若不清楚自身在該專案的角色邊界，常發生「該做未做」或「越俎代庖」的現象。

2. 因應對策：

• 建立專案職能標準手冊：明確定義各專案角色之輸入、產出、技能門檻與交付成果。

核心觀念

1. 軟體專案風險（Software Project Risk）之定義： 依據國際軟體工程權威 Roger S. Pressman 及國際專案管理學會（PMI PMBOK）之定義，風險係指「在專案生命週期中，未來可能發生、具不確定性，且一旦發生將對專案目標（範疇、時程、成本或品質）產生負面衝擊的潛在事件或狀況」。 風險具備兩大核心特徵：

• 不確定性（Uncertainty）：該事件可能發生也可能不發生，其發生機率介於 0 與 1 之間（$0 < P < 1$）。若發生機率為 1，則已屬「問題（Issue/Problem）」，而非風險。
• 損失（Loss / Impact）：該事件一旦發生，將導致非預期的後果、資源浪費或目標偏離，以衝擊程度（$L$）表示。 專案管理上常以**風險暴露度（Risk Exposure, $RE$）**量化評估： $RE = P \times L$ 其中 $P$ 為發生機率（Probability），$L$ 為損失程度（Loss/Impact）。

2. Pressman 軟體風險分類架構（Risk Categories）： 軟體專案風險可藉由「風險檢核表（Risk Item Checklist）」進行識別。Pressman 將軟體專案之潛在風險依來源劃分為：產品大小（Product Size）、客戶特性（Customer Characteristics）、開發技術（Technology to be built）、人員與團隊（Staff Size and Experience / People）、流程成熟度（Process Definition and Maturity）等關鍵維度。

---

解題方法

本題為標準的「觀念定義＋五維度實務分析」申論題，解題切入點如下：

1. 第一部分：風險定義 精準闡述學理定義，點出「不確定性」與「衝擊／損失」兩大要件，並列出數學模型 $RE = P \times L$，展現扎實的學科理論基礎。
2. 第二部分：五大層面探討與問題集設計 依題目指定之五大構面（產品大小、客戶、技術、人員、流程成熟度）逐一展開：

• 先以 2～3 點歸納該維度之「主要風險成因」。
• 針對該維度設計專屬「風險檢核問題集（Checklist Questions）」。依題目硬性規定，每組問題集數量嚴格維持至少 4 題。問題設計須具備「實務診斷性」，通常以封閉或半封閉式問句（「是否……？」）引導專案經理（PM）進行是／否評估與風險計分。

---

選項分析

本題為公職高資位申論題，非選擇題。此處針對題目所規範的「五大分析層面」之內涵邊界與評估核心進行定位，避免各層面內容混淆或重疊：

1. 產品大小（Product Size）：聚焦於軟體資產的「物理與邏輯規模」（如程式碼行數、功能點、外部介面數、資料量），規模呈非線性擴大時，將巨幅推升系統整合與測試難度。
2. 客戶（Customer）：聚焦於「需求來源的穩定度與互動品質」（如決策授權、參與意願、需求變更頻率、溝通管道），客戶端的不確定性常是專案範疇蔓延（Scope Creep）的主因。
3. 技術（Technology）：聚焦於「實作工具與系統架構的複雜度及新穎性」（如新技術演算法、硬體驅動、跨系統相容性、效能瓶頸），強調技術成熟度與團隊掌握度。
4. 人員（People）：聚焦於「人力資源的質、量與組織動態」（如領域知識落差、關鍵人員流失率、溝通成本、兼任多專案問題）。
5. 流程成熟度（Process Maturity）：聚焦於「軟體工程制度的標準化與落實程度」（如 CMMI 水準、變更控制、品質保證 QA、軟體組態管理 SCM）。

---

解題技巧

1. 嚴守題數限制：題幹明訂「每組問題集不得少於四題」，閱卷評分時題數為硬指標，每組務必清楚列出 1、2、3、4 編號，不可精簡為三題或合併敘述。
2. 問題設計具「實務可操作性」：問題不可太空泛（例如「技術好不好？」），必須具備專案經理在規劃期（Planning Phase）或啟動期（Initiation Phase）能直接向團隊或業主提問的具體性（例如「關鍵技術是否經過概念驗證 PoC？」）。
3. 扣合軟體工程標準術語：大量運用「功能點（Function Points, FP）」、「範疇蔓延（Scope Creep）」、「組態管理（SCM）」、「概念驗證（PoC）」、「CMMI」等專有名詞，提升專業辨識度。

---

【答案】

一、 風險之定義（Definition of Risk）

在軟體專案管理中，「風險（Risk）」係指在未來可能發生、具有不確定性，且一旦發生將對專案目標（如時程、成本、範疇、品質）造成不利負面影響的潛在事件或狀況。

風險具備兩大核心要素：

1. 不確定性（Uncertainty）：該事件可能發生也可能不發生，其發生機率 $P$ 介於 $0 < P < 1$ 之間。若發生機率為 1，則已轉變為已實現的「問題（Issue）」；

核心觀念

本題評量考生對軟體專案管理（SPM）中「組織架構」、「品質管制」與「進度監督控制」三大經典定律與實務現象的掌握度，以及將管理理論落實於軟體開發生命週期（SDLC）之實務應用能力：

1. 康威定律（Conway's Law）：系統架構與組織溝通結構的同構性（Isomorphism）。
2. 帕雷托原理（Pareto Principle / 80/20 法則）：品質管理中「關鍵少數與微不足道多數（Vital Few and Trivial Many）」之資源聚焦原則。
3. 90% 症候群（90% Syndrome / Ninety-Ninety Rule）：進度回報中的主觀樂觀偏差（Optimism Bias）與專案末期邊際成本激增現象。
4. SDLC 落地實踐：以客觀度量指標（如 0/100 規則、DoD、自動化測試覆蓋率）取代主觀進度評估。

---

解題方法

1. 分項界定與多維說明：針對三項名詞，採取「定義出處 $\rightarrow$ 核心意涵 $\rightarrow$ 專案管理實務意義」的三層次結構論述，展現知識深度。
2. 單一階段聚焦突破：第二子題要求「擇一合適階段」，選定最容易出現且最易根治 90% 症候群的**「實作與編碼階段（Implementation / Coding Phase）」**（亦可選整合測試階段），從「進度度量機制」、「任務分解技術」、「品質門檻把關」三管齊下舉例說明。

---

解題技巧

1. 標題條列化：國考閱卷時間極短，專有名詞必須標註英文，並以加粗標題切出「定義、管理應用、解決方案」。
2. 避免空泛口號：回答「如何解決 90% 症候群」時，切忌僅寫「加強溝通、加強督導」，必須提出具體工具與度量機制（例如：0/100 規則、Definition of Done、持續整合 CI、程式碼覆蓋率）。
3. 首尾呼應：將第一小題的觀念（如帕雷托原理的關鍵少數、客觀驗證）融入第二小題的方法中，展現體系化的答題邏輯。

---

【答案】

一、名詞解釋

（一）康威定律（Conway’s Law）

1. 定義與出處：由電腦科學家梅爾文·康威（Melvin Conway）於 1967 年提出，其核心主張為：「設計系統的組織，其產生的架構設計必然是該組織溝通結構的翻版（Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations）。」
2. 核心意涵：軟體的架構、模組邊界與介面切分，本質上反映了研發團隊部門劃分、團隊邊界與人際溝通管道。若組織內部壁壘分明、跨部門溝通成本高昂，軟體系統將演變出高耦合或介面脆弱的單體架構。
3. 專案管理應用：專案經理可運用「逆康威定律（Inverse Conway Maneuver）」，欲達到鬆耦合、高內聚的微服務架構（Microservices），應先將團隊重組為跨功能（Cross-functional）、圍繞業務領域（Business Domain）的小型敏捷自主團隊，使組織結構主動引導出理想的系統架構。

（二）帕雷托原理（Pareto Principle）

1. 定義與核心：又稱 $80/20$ 法則（The 80/20 Rule），由經濟學家帕雷托（Vilfredo Pareto）觀察所得，後由品管大師朱蘭（Joseph Juran）推廣於品質管理中。其核心指出：在多數系統中，約 $80\%$ 的結果（問題、影響）往往導因於 $20\%$ 的原因（關鍵少數，Vital Few）。
2. 專案管理應用：

核心觀念

本題旨在評量高階資訊管理人員對於現代專案管理方法論的體系掌握度，重點在於：

1. 精實思維（Lean Thinking）之定義與核心原則：源於豐田生產系統（Toyota Production System, TPS），後由 Mary & Tom Poppendieck 等學者推廣至軟體工程領域（Lean Software Development）。其核心在於「極大化客戶價值（Maximize Value）」、「消除流程浪費（Eliminate Waste / Muda）」與「持續改善（Continuous Improvement / Kaizen）」。
2. 敏捷專案管理（Agile Project Management）之核心意涵：源於 2001 年《敏捷宣言》（Agile Manifesto），以適應性（Adaptive）、增量迭代（Iterative & Incremental）、跨功能自主團隊與快速反饋為核心。
3. 兩者之系譜交集與核心分野：理解敏捷與精實並非互斥，而是具有同源價值但落實視角不同——敏捷聚焦於「應對需求變更與產品迭代演進」，精實聚焦於「流程整體的連續流動與消弭無價值作業」。

---

解題方法

本題為標準的觀念闡述與比較型申論題，作答應採取「破題定義 $\to$ 共同點提煉 $\to$ 差異性維度對比」的三段式論述：

1. 定義精實專案管理：不能僅泛泛定義，必須寫出其管理哲學（價值、浪費、持續改善）、核心實務（價值流程圖 VSM、在製品限制 WIP Limit、拉動系統 Pull System）與軟體七大浪費之對應，展現高考二級研究層次的學理深度。
2. 歸納共同點：從「價值取向」、「應變文化」、「團隊自主」與「小批量交付」等高層次共通理念切入。
3. 剖析差異性：從「起源背景」、「核心著眼點」、「運作節奏（Cadence）」、「排程與控制機制」、「關鍵度量指標（Metrics）」等多個構面建立對照，並輔以表格呈現，利於閱卷委員在短時間內精準掌握得分要點。

---

選項分析

本題為高考二級專門技術申論題，非選擇題。就申論結構的評分構面進行「論述要點剖析」：

• 精實專案管理定義要點：
• 必須涵蓋：消除浪費（Muda）、價值流程（Value Stream）、流動（Flow）、拉動（Pull）、持續追求完美（Perfection）。若只回答「省錢、精簡人手」為嚴重錯誤，精實的核心是極大化價值與最佳化流動，而非單純裁減成本。
• 共同點論述要點：
• 必須涵蓋：兩者皆打破傳統瀑布式（Waterfall）的嚴格前置計畫與預測控制；皆主張快速獲取顧客反饋、跨功能協作與賦權授權（Empowerment）。
• 差異性論述要點：
• 常見盲點：誤將精實與敏捷截然對立。正確論述應指出：精實著眼於「系統性流程流動（Systemic Process Flow）」，敏捷（以 Scrum 為代表）著眼於「固定時間盒（Timeboxing）內的軟體功能增量開發」。

---

解題技巧

1. 專有名詞精準化：答題時務必寫出關鍵英文術語，如 Value Stream Mapping (VSM)、Work-In-Progress (WIP)、Lead Time、Cycle Time、Timebox、Velocity，此為獲得高分之評分標竿。
2. 善用比較矩陣：比較題最忌諱通篇純文字散漫陳述，使用結構化對照表格能展現組織力與邏輯條理性。
3. 軟體情境連結：論述精實浪費時，精準舉出軟體開發對應的浪費（如：未完成的工作、過度設計、額外功能、交接延宕等），緊扣《軟體專案管理研究》之科目特性。

---

【答案】

一、精實專案管理（Lean Project Management）之意涵

精實專案管理係將精實製造思維（源自 Toyota Production System, TPS）導入專案管理與軟體工程的系統化方法論。其核心宗旨為**「極大化客戶價值，極小化流程浪費」**，透過端到端的系統性檢視，建構流暢無阻的價值交付流。其核心內涵包含以下主軸：

1. 核心管理原則：

• 消除浪費（Eliminate Waste）：剔除所有未對最終客戶產生價值的活動（日語稱 Muda）。在軟體專案中，典型浪費包含：在製品半成品（Partially Done Work）、未被使用的額外功能（Extra Features）、多工切換的重啟成本（Task Switching）、等待與審批延遲（Delays）、跨部門交接遺失（Handoffs）及缺陷修正（Defects）。
• 建構內建品質（Build Integrity In）：非依賴事後檢驗，而是透過自動化測試、持續整合（CI）與重構，將品質直接注入流程中。
• 強化知識與學習（Amplify Learning）：透過短週期實驗與客觀數據，促進組織持續學習。