107 國營臺灣鐵路公司不分職等 營運專員-資訊 台鐵營運人員 營運專員(資訊) (系統專案管理) 考古題詳解

核心觀念

瀑布模式（Waterfall Model）是線性、循序的軟體開發模式，通常依序經過可行性研究、需求分析、系統設計、建構、測試及安裝等階段。各階段完成後，須經檢查與認可，再進入下一階段；因此它重視階段文件與審核，但對開發後期才發現的問題，變更與回溯成本通常較高。

解題方法

先辨認瀑布模式的兩項特徵：階段循序推進與階段審核。再檢視選項是否把「回溯修正」說得過於絕對。瀑布模式並非完全不能回頭修正；發現錯誤或需求變更時，通常回到受影響的前置階段修正並重新驗證，不代表一律回到最初階段重做。

選項分析

• (A) 正確。 瀑布模式又稱「一次性」或「一次通過」模式（One-Shot／Once Through），用以描述開發活動依序進行、原則上逐階段完成的特性。
• (B) 正確。 常見的瀑布模式開發活動包括可行性研究、需求分析、設計、建構、測試及安裝，與選項所列相符。
• **(C) 正確。

核心觀念 本題測驗結構化系統分析與設計（Structured Analysis and Design）中核心工具——資料流程圖（Data Flow Diagram, DFD）​的基本構成要素、標記圖號（Notations）、別名以及階層化架構。

DFD 主要是以圖形化方式，描繪資料在系統中的流動、處理、儲存及與外部實體之間的互動。目前業界與國家考試最常考的兩大主流符號系統為 Yourdon / DeMarco 標記法 與 Gane & Sarson 標記法。DFD 必定由以下四項核心元素組成：

1. 處理（Process）：表示對資料進行轉換或運算的作業單元。

• Yourdon / DeMarco：以圓形（Circle）​表示。
• Gane & Sarson：以圓角矩形（Rounded Rectangle）​表示。

2. 資料流（Data Flow）：表示資料移動的方向。

• 符號：以帶有方向的箭頭（Arrow）​表示。

3. 資料儲存（Data Store）：表示靜態存放資料的檔案或資料庫。

• Yourdon / DeMarco：以兩條平行線（Parallel Lines）​表示。
• Gane & Sarson：以右側開放之三邊長方形（Open Rectangle）​表示。

4. 外部實體（External Entity / Source or Sink）：表示系統界限外提供資料來源或接收資料目的之人、組織或外部系統。

• 符號：通常以方形／矩形（Square / Rectangle）​表示。

解題方法 本題為基礎觀念題，切入點為比對 DFD 的「圖號（幾何圖形）」與「各組成單元之語意定義」：

1. 先確認 DFD 元素是否有方形、圓形/圓角方形、平行線、箭頭四種（檢視 B）。
2. 再比對「處理（Process）」對應的圖形是圓形或圓角方形，而非純方形（檢視 C）。
3. 最後驗證最高階層 DFD（脈絡圖 Context Diagram）之特性與數量（檢視 D）以及 DFD 之常見別名（檢視 A）。

選項分析

• (A) 正確：在經典的 Yourdon / DeMarco 標記法中，處理（Process）是以圓形呈現，外觀形似氣泡，因此資料流程圖常被通俗地稱為「氣泡圖」（Bubble Chart）。
• (B) 正確：DFD 正是由這四種基本幾何符號構成：

• 方形：外部實體（External Entity）
• 箭頭：資料流（Data Flow）
• 圓形或圓角方形：處理（Process）
• 兩平行線或三邊長方形：資料儲存（Data Store）

核心觀念

本題考查專案管理軟體的需求分析與選擇原則。選用軟體時，應先確認專案與使用者的實際需求，再依專案特性評估功能是否適用。常見考量包括：

• 專業背景與特殊需求：不同產業、專案類型及使用者的工作方式，會影響所需功能。
• 專案規模與適用性：小型專案與大型、複雜專案，對排程、資源、成本及協作功能的需求不同。
• 需求優先：軟體應配合專案需求，而不是只因熟悉度或一般辦公軟體的選用方式而決定。

解題方法

先辨認題目問的是「何者有誤」。選擇軟體的基本原則是依需求與專案情境評估，因此可逐項檢查各選項是否符合「需求導向、因專案特性而異」的原則。宣稱專案管理軟體與一般辦公室軟體的評估標準相同者，忽略了專案管理軟體的專業功能與專案差異，為錯誤敘述。

選項分析

(A) 正確。 評估與選擇時，須考量使用者的專業背景，以及產業或專案所具有的特殊需求。不同使用情境可能需要不同的排程、資源管理或報表功能。

核心觀念

黑箱測試（Black-box Testing）是依據系統的需求與功能規格設計測試案例，輸入測試資料，再比對實際輸出與預期結果是否一致，不以程式內部結構、演算法或執行路徑作為設計依據。

本題主要考查三項觀念：

• 窮盡測試：測試所有可能的輸入值及其組合，理論上最完整，但實務上常因組合數過多而無法執行。
• 等價類別劃分：將輸入範圍分成具有相似處理特性的類別，再從各類別挑選代表值，並涵蓋有效與無效輸入。
• 邊界值分析：針對輸入範圍的邊界及其相鄰值進行測試，因為上下限判斷容易出現錯誤。

解題方法

以「依規格測試功能、理論上涵蓋全部輸入、實務上挑選代表資料」為判斷主軸。

先確認選項是否正確描述黑箱測試，再檢查測試資料的選取方式。完整涵蓋所有輸入是理論理想；實務上則以等價類別與邊界值等方法，在有限成本內提高測試涵蓋程度。

選項分析

(A) 錯誤。

黑箱測試人員需要知道的是系統的對外功能、輸入條件與預期輸出，並不要求知道內部程式內容。

本選項將「知道系統的內容」列為黑箱測試的特徵，混淆了功能規格與內部實作。判斷黑箱測試的關鍵，在於測試案例依據外部規格設計，而非依據內部結構。

(B) 正確。

若能將所有可能的輸入值及其組合逐一輸入，並核對輸出結果，即屬於窮盡測試，在輸入涵蓋程度上最完整。

但實際系統的輸入組合通常極為龐大。例如，兩個輸入欄位各有 $1{,}000$ 種取值，就有：

種組合。因此，本選項所述「雖不太實際」符合窮盡測試的限制；「最佳」應理解為理論上的完整涵蓋，並非實務上成本效益最高的方法。

(C) 錯誤。

核心觀念

螺旋模式（Spiral Model）是以風險分析為核心的軟體開發生命週期模式。開發過程以多次循環逐步推進；每一圈通常會確認目標、分析並降低風險、開發與驗證成果，再規劃下一輪。常見的風險降低方式包括製作雛型、模擬、模型建立與標竿比較。

解題方法

先掌握螺旋模式的兩項特徵：一是及早識別並處理風險，二是透過反覆開發與使用者回饋逐步釐清需求。再檢查各選項是否符合這些特徵，尤其留意「不必確認與驗證」這類絕對敘述：螺旋模式每一輪都需要評估成果，確認是否達到目標並決定後續方向。

選項分析

• (A) 正確。 螺旋模式在開發早期便進行風險分析，有助於及早發現技術、成本或需求等風險，並規劃降低風險的方法。
• (B) 正確。 螺旋模式採反覆開發，常透過雛型或階段性成果取得使用者回饋，逐步確認與修正需求。
• (C) 錯誤。 螺旋模式並非免除確認與驗證。

核心觀念

螺旋模式（Spiral Model）以一連串循環逐步開發系統，每一圈通常分成四個象限，依序進行：

1. 第一象限：目標、替代方案與限制的確認
2. 第二象限：替代方案評估、風險分析，以及風險降低措施（如建立雛型）
3. 第三象限：開發與驗證下一階段產品
4. 第四象限：規劃下一個循環

本題考查各象限的工作內容，關鍵是辨認「風險分析及建立雛型」屬於評估與降低風險的階段。

解題方法

先看題幹中的「風險分析」與「建立雛型」。螺旋模式在第二象限評估不同方案的風險，並可藉由建立雛型、模擬或其他分析方式降低不確定性；風險處理後，才進入第三象限進行實際開發與驗證。因此，本題所述工作位於第二象限。

選項分析

• (A) 第一象限：錯誤。​第一象限主要界定本次循環的目標、可行方案及限制，尚非風險分析與雛型建立的主要階段。
• **(B) 第二象限：正確。

核心觀念

本題測驗軟體專案管理與軟體工程中軟體雛型製作（Software Prototyping）​的核心定義、分類及其在需求工程與風險管理中的定位。

1. 軟體雛型（Software Prototype）的定義與目的： 在系統開發生命週期（SDLC）初期，為了協助使用者與開發團隊釐清模糊、不確定的系統需求，快速建構出具備部分關鍵特徵、可供操作或視覺化的系統模型。雛型的主要目的在於降低需求變更風險、促進利害關係人溝通與驗證技術可行性。

2. 雛型的兩大主要分類：

• 拋棄式雛型（Throwaway Prototyping / Rapid Prototyping）：專注於探索與釐清未知的需求或驗證高風險技術。當需求確定後，該雛型即被捨棄，正式系統將依據確立的規格從頭嚴謹開發，不保留雛型的程式碼。
• 演進式雛型（Evolutionary Prototyping）：從已明確的核心需求開始建構雛型，透過使用者持續操作與回饋，反覆迭代（Iteration）擴充與精煉，雛型最終會「演進」為正式上線的系統產品。

3. 雛型的完整度與品質特性： 雛型強調的是「快速獲取回饋」與「低成本試錯」，常見形式包含只做介面不含底層邏輯的水平雛型（Horizontal Prototype），或只針對特定複雜演算法實作的垂直雛型（Vertical Prototype）。因此，雛型刻意忽略非功能性需求（如安全性、高併發效能、容錯與完整例外處理），絕不要求具備完整功能與正式上線品質。

解題方法

本題解題切入點為​「軟體雛型分類的專有名詞定義」​與​「雛型開發哲學（快速試錯 vs 完整工程）」：

1. 比對專有名詞與特徵：檢視選項中關於雛型分類的敘述，「用完即拋棄」與「演進式」在語意與軟體工程定義上完全對立，可直接判定該選項存在重大概念謬誤。
2. 檢視雛型的本質與實務價值：評估雛型在開發流程中的角色（溝通媒介、探索限制、降低風險），快速過濾符合雛型實務效益的正向敘述。

選項分析

• (A) 敘述錯誤（本題選 (A)）： 「用完就拋棄」對應的專有名詞為拋棄式雛型（Throwaway Prototyping）；而演進式雛型（Evolutionary Prototyping）​的核心概念是「由淺入深、逐步擴充」，雛型會持續保留並演進為正式軟體，兩者定義完全相反。選項將拋棄式特徵冠以演進式之名，觀念明顯混淆。

• (B) 敘述正確： 在需求分析階段，終端使用者常有「看到實物前不知道自己要什麼」（IKIWISI, I Know It When I See It）的現象。具體可操作的圖形介面與互動流程，能打破文件文字描述的抽象與歧義，是開發者與使用者校準認知、引導潛在需求的最佳溝通媒介。

核心觀念

本題考專案估算時，需納入哪些主要考量。估算不只是預測專案成本，也要衡量專案是否做得到、投入是否值得，以及執行風險是否可接受。常見的三項主要因素是：

1. 可行性：評估技術及資源條件能否支持專案。
2. 成本與效益：衡量專案投入與預期效益是否相稱。
3. 風險：辨識可能影響專案成本、時程或成果的不確定因素。

解題方法

逐一比對選項與上述三項因素。技術可行性研究對應可行性；成本與利益的平衡點對應成本效益；專案帶來的風險則對應風險評估。剩下的「專案管理人力的限制」屬於專案資源與執行條件的考量，並非題目所問的三個主要因素之一。

選項分析

• (A) 技術可行性研究：屬於三項主要因素。 專案估算須考量技術是否可行；若技術能力、設備或系統條件不足，估算的時程與成本就缺乏實現基礎。

• (B) 成本與利益的平衡點：屬於三項主要因素。 評估專案所需投入與預期效益是否合理，是判斷專案價值的重要依據。

核心觀念

本題考查漸進式交付模式中的需求優先順序分類法 MoSCoW。漸進式交付會將系統功能分批完成，因此必須先區分需求的重要性，決定哪些功能優先交付、哪些可以延後。

依本題採用的用語，四類需求如下：

須注意，現今常見的標準表述將 W 寫為 Won’t Have this time，表示「本次不納入」。本題則採用「Want Have」的教材用語，重點在於將此類需求延後處理。名稱中的兩個小寫 o 是為了方便發音，並非額外的需求分類。

解題方法

本題問「不屬於」，應比對各選項的英文名稱與分類意義。

MoSCoW 的 M 是 Must，意思是「必須」，不是 Most「多數」。因此，將 M 寫成「Most Have」的選項即為答案。

選項分析

• (A) 多數包含（Most Have）：不屬於，為本題答案。 正確名稱應為 Must Have（必須包含）。

核心觀念

本題考查系統開發生命週期中，各種開發模式對「需求明確度」與「交付速度」的適應性。

• 瀑布模式：依序完成需求分析、設計、開發、測試與維護；前一階段的成果確定後，才進入下一階段。適合需求明確、變動較少的系統。
• 漸增模式：分批開發並交付系統功能，先提供核心功能，再逐步增加功能，能較早交付可用成果。
• 雛型模式：先建立初步版本供客戶試用，藉由回饋釐清及修正需求。
• 螺旋模式：以反覆循環方式逐步開發，並在每一循環中評估與處理風險，適合大型或高風險專案。

解題方法

題幹的關鍵條件是「需求並不明確」以及「要求快速開發」。需求不明確時，開發方式應能容納回饋、調整或分批交付；若模式仰賴前期完整確認需求，後續需求變動就容易造成返工。

因此，應找出最依賴需求事先明確、階段依序推進，且不利於快速因應變動的模式。

選項分析

(A) 漸增模式：錯誤。 漸增模式可將系統拆成多個功能增量，先完成重要或核心功能，再逐步擴充。這種方式能提早交付部分成果，並讓後續開發依回饋調整，與題幹的快速開發需求相符。

(B) 瀑布模式：正確。 瀑布模式強調階段依序進行，通常須在需求分析階段充分確認需求，才能據以完成設計與開發。若需求不明確或持續變動，後續修改可能牽動已完成的階段，增加成本與時程；也不利於快速交付。因此它是四種模式中最不適合者。

核心觀念

本題考查專案管理工具中，哪一種最能呈現各項任務之間的相依關係與執行順序。

PERT 圖（計畫評核術圖）以節點和箭線表示專案活動及其先後關係，能清楚呈現哪些任務必須先完成、哪些任務可以接續或並行，因此適合用來表達任務的相依性與順序。

解題方法

先抓題幹關鍵詞：「所有任務的相依性」與「任務間的順序排列」。這是在問專案活動之間的邏輯先後關係，應選能以網路圖呈現活動順序的工具。甘特圖著重排程的時間軸呈現；WBS 著重工作分解；CASE 工具則支援系統開發。依題意選擇 PERT 圖。

選項分析

• (A) PERT 圖：正確。​以網路圖呈現活動及其先後依存關係，可用來分析任務順序與專案流程。
• (B) 甘特圖：錯誤。​以時間軸和長條呈現各任務的開始、結束與工期，便於掌握排程進度；呈現任務相依性並非其主要強項。
• **(C) CASE 工具：錯誤。

核心觀念

V 型模式（V-Model）將開發流程排成左右對稱的 V 字形。左側為定義與設計階段，由上而下逐層細化；右側為測試階段，由下而上逐層驗證。左右兩側一一對應，左側每個階段的產出，都在右側找到對應的測試層級作為驗證依據。

• 左側（由上而下）：需求分析 → 高階設計（系統架構）→ 詳細設計 → 程式撰寫（編碼）
• 右側（由下而上）：單元測試 → 整合測試 → 系統測試 → 驗收測試
• 對應關係：需求分析 ↔ 驗收測試；高階設計 ↔ 系統測試；詳細設計 ↔ 整合測試；程式撰寫 ↔ 單元測試

各階段完成後都會進行審查（Review），以確認產出品質。本題四個選項即為左側各層級的審查，考點在於辨別哪一個審查屬於「高階規劃」層級。

解題方法

題目所稱「高階規劃」即系統層級的架構規劃，也就是高階設計。解題步驟為：先確認各選項審查所對應的層級，再找出與「高階」一致的那一項。各審查的層級由高到低為：需求審查 → 架構審查 → 設計審查 → 程式審查，因此只需比對層級，無需逐項背誦定義。

選項分析

• (A) 需求審查：錯誤。 需求審查針對需求分析階段的產出（需求規格書），確認使用者需求是否完整、一致且可驗證，回答的是「系統要做什麼」。它屬於定義問題的層級，並非規劃系統如何構成，且與右側的驗收測試對應。
• (B) 架構審查：正確。 架構設計即高階設計，負責決定系統的整體結構、子系統劃分、模組間介面、技術選型與部署方式。架構審查即檢視這些高階決策是否滿足需求、具備擴充性與可維護性，屬於 V 型左側的高階規劃核心，與右側的系統測試對應。
• (C) 設計審查：錯誤。 設計審查通常指詳細設計的審查，針對模組內部的演算法、資料結構、類別與介面細節。

核心觀念

軟體工程的「4P」包含人（People）、產品（Product）、流程（Process）與專案（Project）。這四個構面彼此關聯，但一般認為人是最重要的構面：軟體由人員規劃、設計、開發、測試與維護，其他構面的安排與執行也仰賴參與者的能力及協作。

解題方法

辨認題目問的是 4P 中哪一個構面最重要。依軟體工程與專案管理的常見觀念，應選「人（People）」；具備合適的人才與有效溝通，才能把產品需求、開發流程與專案計畫落實。

選項分析

• (A) 產品（Product）：指要建置的軟體及其需求、功能與品質目標，是重要構面，但不是題目所問的最重要分量。
• (B) 專案（Project）：涵蓋規劃、時程、資源與風險等管理工作，協助控制開發活動，並非最重要的構面。

核心觀念

本題考查軟體專案管理的三項基本觀念：範疇明確、全員參與、管理涵蓋完整生命週期。

「軟體範疇」是指軟體要達成的目標、提供的功能、交付的成果，以及工作邊界與限制。專案初期必須先釐清範疇，才能據以估算成本、安排時程、配置人力及管理風險。

軟體開發仍具有需求變動、技術風險及估算誤差等不確定性，因此需要持續監視與控制，並由專案經理及開發團隊共同參與。

解題方法

逐項檢查敘述是否符合下列原則：

• 責任分工不等於責任切割：專案經理負責統籌，軟體工程師仍須參與進度、品質及風險管理。
• 技術進步不等於不確定性消失：工具可以降低風險，無法消除所有變動。
• 範疇是規劃的基礎：先釐清要做什麼，才能決定如何做、由誰做及何時完成。
• 交付不代表所有管理責任立即終止：仍須依專案約定處理驗收、移交及支援維護工作。

據此，符合基本原則的是選項（C）。

選項分析

（A）錯誤：監視與控制也需要軟體工程師參與。

專案經理負責建立與統籌監控機制，但工程師必須提供實際進度、回報問題與風險、執行品質檢查及配合矯正措施。例如，開發人員發現系統整合困難時，應即時回報，以利調整計畫。「與軟體工作師無關」將管理責任完全切割，並不正確。

（B）錯誤：不確定性仍是軟體專案的重要特徵。

即使開發工具與技術進步，仍會面臨使用者需求改變、新技術適用性未明、工作量估算偏差及外部系統介面異動等問題。因此，軟體專案仍須進行風險管理與變更管理。

（C）正確：專案初期應釐清軟體範疇，且內容必須清楚可理解。

核心觀念

本題考查專案風險的「風險避免」。風險避免是透過改變計畫或活動，直接不承擔某項風險，例如取消高風險計畫，或不投入可能造成重大損失的專案。

解題方法

抓住題幹中的「不從事」與「取消」：這兩種作法都是停止或不開始可能帶來風險的活動，使該風險不再由專案承受。因此，題目描述的是風險避免。

選項分析

• (A) 風險預防：錯誤。 風險預防著重於採取措施降低風險發生的機率，例如加強測試、教育訓練或改善作業程序；仍會進行相關活動。
• (B) 風險避免：正確。 透過不從事高風險專案或取消高風險計畫，避開風險來源。
• **(C) 風險解決：錯誤。

核心觀念

本題考查資訊系統委外的優缺點。委外是企業將資訊系統的開發、維護或營運工作交由外部廠商負責，藉此運用廠商的專業與資源。常見優點包括降低自行投資與建置的負擔；常見缺點則包括組織對承商的依賴增加、內部員工士氣受影響，以及管理彈性或應變速度受限。

解題方法

逐項檢視各敘述是否符合委外的典型特性。題目問「何者有誤」，因此要找出與委外的風險或優缺點相反的敘述。

選項分析

• (A) 可減低投資風險：正確。 企業可減少自行建置資訊系統所需投入的資金、人力與設備，並運用承商既有的技術及服務，因此能降低部分投資與建置風險。
• (B) 可掌握主動不受委外承商控制：錯誤。 委外後，企業在系統知識、技術維護或日常營運上可能依賴承商，承商也可能掌握關鍵資訊與服務能力。企業仍可透過契約、監督及管理機制降低依賴，但不能據此認定委外必然讓企業完全掌握主動、不受承商控制。
• **(C) 可能打擊員工士氣：正確。

核心觀念

在專案管理（Project Management）的專案收尾與終止階段中，專案未達預期目標而被迫提前結束稱為「專案提早終止」或「專案中止」（Premature Project Termination）。根據專案管理經典理論（如 Meredith & Mantel 等學者之論述），導致專案中止的核心決策因素主要歸納為以下三大構面：

1. 技術因素（Technical Factors）：專案面臨無法突破的技術瓶頸、關鍵性能規格無法達標，或市場上已出現顛覆性之替代技術，導致原專案技術失去競爭力與實用價值。
2. 經濟因素（Economic Factors）：專案開發成本嚴重超支、投資報酬率（ROI）或淨現值（NPV）大幅低於預期、市場需求萎縮或消失、競爭對手搶先推出更具優勢之低價產品等。
3. 組織因素（Organizational Factors）：母組織的長期策略目標或核心業務轉向、高階主管或專案發起人（Sponsor）更迭導致專案失去政治與資源支持、組織內部不同部門或專案間的資源排擠與衝突等。

在專案終止決策的標準理論架構中，「社會因素」屬於總體外部環境（如 PEST 分析）的範疇，並非專案中止理論所歸納的核心直接因素分類。

解題方法

本題為專案管理收尾階段的「專案中止原因分類」記憶與觀念題。解題切入點如下：

1. 辨識專案終止的決策層次：專案中止的評估重點在於「技術是否可行（技術因素）」、「財務商業是否劃算（經濟因素）」以及「是否符合母機構現行發展方針（組織因素）」。
2. 區分環境分析與專案決策架構：避免將巨觀外在環境分析工具（如 PEST：政治、經濟、社會、技術）與專案中止原因分類混淆。比對專案中止的三大直接因素「技術、經濟、組織」，即可判斷出非屬標準分類之選項。

選項分析

• (A) 社會因素：非屬於專案中止的標準核心因素。社會因素（如人口結構變遷、文化價值觀改變）通常屬於總體外在巨觀環境之變數，雖然可能間接影響市場偏好，但在專案管理學科中，專案中止決策是由具體的技術障礙、財務經濟損失或組織內部策略轉變所直接觸發，故「社會因素」不屬於專案中止的主要分類項目，為本題應選答案。
• (B) 經濟因素：屬於專案中止的因素。

核心觀念

物件導向的「再運用」是指把已寫好的程式類別或功能用於其他程式，減少重複撰寫。繼承可讓子類別取得父類別的屬性與方法，並在此基礎上擴充或修改，因此能提高程式碼的重複使用率。

解題方法

題幹的關鍵字是「支援軟體再運用」與「降低重複程式碼撰寫」。依此判斷，應選擇能讓新類別沿用既有類別功能的物件導向特質，即繼承。

選項分析

• (A) 繼承：正確。 子類別可承接父類別既有的屬性與方法，直接重用程式碼，也可依需求新增或覆寫功能。
• (B) 封裝：錯誤。 封裝是將資料與操作資料的方法組合在一起，並控制外部存取，以維護資料完整性；主要目的不是降低重複程式碼。
• (C) 多型：錯誤。 多型讓不同類別的物件能以共同介面呈現各自的行為，提升程式的彈性與可擴充性；

核心觀念

本題考查「文件檔案管理」與「知識管理」的關係。

知識管理是將組織的知識加以取得、整理、儲存、分享及應用，使個人經驗能轉化為組織可持續利用的資產。組織中的知識主要分為：

• 外顯知識：能以文字、圖表等形式記錄，例如作業手冊、技術文件、專案報告。
• 內隱知識：存在於個人經驗、技能與判斷中，例如資深人員的故障排除經驗。

文件檔案管理透過分類、編目、保存、檢索及版本管理，使已記錄的知識得以保存與取用，因此是知識管理的基礎。

解題方法

從「管理對象」與「直接目的」切入判斷：

文件檔案管理的對象是承載資訊與知識的文件，其目的在於讓組織成員能找到、理解並使用既有成果。這正是知識保存、分享與再利用的前提，因此最直接對應「知識管理」。

例如，將系統開發的需求規格、設計文件及結案報告妥善歸檔，後續專案即可查閱並沿用經驗，減少重複摸索與相同錯誤。

選項分析

• (A) 財務管理：錯誤。 財務管理著重資金籌措、投資決策及資金運用。財務報表與憑證需要文件管理支援，但這不是題目所指的直接概念關係。

• (B) 風險管理：錯誤。 風險管理著重風險的辨識、分析、評估、因應及監控。文件紀錄可提供風險分析所需資料，但文件檔案管理的主要意義不在於管理風險。

核心觀念

本題考查專案團隊中的功能部門技術代表。此角色由功能部門派出，與專案管理者及其他團隊成員合作，提供技術建議、協調專案工作，並適時代表原部門參與專案活動。

解題方法

抓住題幹中的角色特徵：「從功能部門提供支援」、「提供技術性建議」及「代表其部門參與專案活動」。這些職責指向功能部門派任的技術代表，而非負責品質管理、現場管理或生產協調的角色。

選項分析

• (A) 品質管理者：錯誤。​主要負責規劃及監督品質相關工作，例如品質標準、品質保證與品質控制；題幹的重點是代表功能部門提供技術支援。
• (B) 功能部門技術代表：正確。​此角色與專案管理者及其他成員合作，提供技術性建議、協調團隊工作，並代表其功能部門參與專案活動，符合題幹描述。
• **(C) 現場管理者：錯誤。

核心觀念

專案計畫書（Project Plan）是整合專案各項管理計畫與執行依據的文件，說明專案如何執行、監控、管理及完成。專案團隊據此協調工作、追蹤進度，並在需要時作為判斷與處理專案問題的依據。

解題方法

題目問的是專案計畫書的「主要用途」，應抓住它對專案執行所發揮的整體指導功能。它不只是經理個人的工作清單，也不僅用於取得客戶同意，而是提供專案執行與管理的共同依據。

選項分析

• (A) 業主要求：錯誤。 業主可能要求提出專案計畫書，但「提出文件的要求」不是計畫書本身的主要用途。
• (B) 專案經理的工作計畫：錯誤。 專案經理會運用計畫書管理專案，但計畫書的適用對象與功能不限於經理個人的工作安排，也供專案團隊及相關人員遵循。
• **(C) 專案執行的指導方針及依據：正確。

核心觀念

本題測驗專案管理知識體系（PMBOK）中專案品質管理（Project Quality Management）​的核心定義與分類。

專案品質管理主要分為三大核心概念：

1. 規劃品質管理（Plan Quality Management）：辨識專案及可交付成果的品質標準，並訂定達成標準的方法。
2. 品質保證（Quality Assurance, QA）：指在品質系統內實施的計畫性、系統化活動，目的在於建立信心，確保專案流程與活動能符合既定的品質標準與作業要求。其核心特徵為​「導向流程（Process-oriented）」​與​「預防缺陷（Prevention）」。
3. 品質管制（Quality Control, QC）：監控並記錄執行品質活動的具體產出結果，評估績效並剔除不合格產品。其核心特徵為​「導向產品（Product-oriented）」​與​「檢驗缺陷（Inspection）」。

解題方法

解題的切入關鍵在於題目中的兩組核心關鍵字：

1. 「計畫性、系統化的品質活動」
2. 「確保專案所有的活動均符合要求流程」

分析此題重點在於​「流程（Process）」​的遵循與改善，而非終端成品（Product/Deliverable）的測試或檢驗。依據專案管理標準定義，透過計畫性與系統化的程序來確保所有工作皆依規範進行、預防錯誤發生的機制，即為品質保證（QA）。

選項分析

• (A) 品質保證（Quality Assurance, QA）：【正確】 品質保證旨在確保專案團隊遵循正確的工作流程，以提供組織內部管理層與客戶足夠的信心，相信專案將會達到既定的品質標準。題幹敘述「運用計畫性、系統化的品質活動，以確保專案所有的活動均符合要求流程」為品質保證的經典規範定義。

• (B) 品質稽核（Quality Audit）：【錯誤】 品質稽核是品質保證過程中所採用的一種​「工具與技術（Tools & Techniques）」，為一種結構化、獨立的審查程序，用以判定專案各項活動是否確實遵循了組織或專案的政策、程序與指南。題幹詢問的是整體的「管理活動／機制」，而非單一審查工具。

• (C) 流程分析（Process Analysis）：【錯誤】

核心觀念

本題考的是專案成本管理的共同責任。成本估計、預算編列與成本控制，都是專案成本管理的重要工作。專案經理通常負責統籌管理，但專案成員也需要了解成本如何估計、預算如何形成，以及成本控制如何影響專案執行。

解題方法

題目問的是「哪些成員所必須了解」，範圍比「由誰負責統籌」更廣。判斷時應區分「管理責任」與「必要知識」：成本管理由特定角色主導，但專案能否在預算內完成，仰賴所有成員理解成本要求並配合控制。

選項分析

• (A) 專案經理：錯誤。 專案經理須掌握成本估計、預算與控制，但題目問的是所有應了解的成員，並非只問主要負責人。
• (B) 專案助理：錯誤。 專案助理可能協助成本資料整理或行政作業，但並非唯一需要了解成本管理的人。
• **(C) 現場管理員：錯誤。

核心觀念

本題考的是專案成本會計系統與專案管理資訊系統的功能範圍及整合關係。

專案成本會計系統（PCAS）​以專案成本資訊為核心，將成本支出與工作項目、專案進度及工作績效相互連結。其用途不只是記錄「花了多少錢」，還包括協助管理者掌握「這些支出對應完成了多少工作」，據以追蹤及控制專案。

專案管理資訊系統（PMIS）​則是整合專案資訊，支援專案規劃、執行、監控與報告的系統。當成本會計系統進一步結合時程、工作進度及其他規劃、控制與報告功能時，其範圍已擴及整體專案管理，因此可視為專案管理資訊系統。

解題方法

採用功能範圍判斷法，依題幹描述的整合程度辨認系統：

1. 成本與進度、績效相連結：表示系統具有專案成本管理及績效追蹤功能。
2. 允許追蹤、控制時程與工作進度：表示功能已不限於會計資料的記錄。
3. 結合其他專案規劃、控制及報告功能：表示系統已整合多項專案管理作業。

其中，第三點是決定答案的關鍵。題目問的是整合後的整體系統名稱，應選擇能涵蓋各項功能的「專案管理資訊系統」。

選項分析

• （A）專案管理資訊系統：正確。 能整合成本、時程、工作進度及績效等資訊，並支援規劃、控制與報告，完整符合題幹描述。

核心觀念

本題考查專案生命週期中的階段關卡（phase gate）​與績效評量點。管理者在特定時間點檢視專案進度、成果及風險，再據以決定專案能否進入下一階段；這類評量點稱為里程碑（milestone）。

里程碑不只是排程上的日期，也可作為管理上的檢核點。它通常沒有工作期間，重點在於標示重要成果或決策時點。

解題方法

抓住題幹中的兩個關鍵訊息：

1. 管理者在特定時間點評估專案狀況。
2. 根據評估結果決定是否進入下一階段。

這描述的是專案階段交接前的檢核關卡，也就是里程碑。監視、測試與展示、設計審查都可能是專案管理活動，但不是題幹所指的通用績效評量點名稱。

選項分析

• (A) 監視：錯誤。 監視是持續追蹤專案進度與績效的活動，並非特定的階段評量點。
• (B) 里程碑：正確。 里程碑是專案中重要的檢核或決策時點；管理者可依評估結果決定專案是否進入下一階段。

核心觀念

資源撫平（Resource Leveling）是專案時程管理中的資源最佳化技術。當多項活動同時需要同一項資源，造成資源需求超過可用量，或資源使用量分布不均時，專案經理會調整活動的開始與完成時間，使資源需求較平穩。此調整可能使專案工期延長。

解題方法

判斷題目問的是「資源撫平時會用到的工具」。可從工具用途切入：資源撫平需要看出各時段的資源需求量，以及需求是否超過可用量；能呈現各時段資源使用量的工具是資源直方圖。

選項分析

• (A) 甘特圖：錯誤。 甘特圖以橫條呈現活動的排程與期間，適合查看活動何時進行，但不是呈現各期間資源需求量的主要工具。
• (B) 資源清單：錯誤。 資源清單列出專案所需或可用的資源種類與項目，無法直接顯示資源需求隨時間的變化。
• **(C) 資源直方圖：正確。

核心觀念

本題旨在測驗專案時程管理中「要徑法」（Critical Path Method, CPM）的核心定義與浮時計算原理。

1. 要徑（Critical Path）之定義：

• 專案網圖中「作業期間最長」的路徑，決定了專案最短完工所需時間。
• 要徑上的活動稱為「要徑活動」（Critical Activities），其總浮時（Total Float, $TF$）通常為零（若專案目標完工日等於計算完工日）。
• 字面陷阱：「要徑（Critical）」是指時程上受緊縮制約、無寬裕時間的路徑，並非指該活動在實質技術、品質或商業價值層面上是「最重要」的。

2. 時間參數與計算公式：

• 順推法（Forward Pass）計算出：最早開始時間（Early Start, $ES$）與最早結束時間（Early Finish, $EF$）。
• 逆推法（Backward Pass）計算出：最晚結束時間（Late Finish, $LF$）與最晚開始時間（Late Start, $LS$）。
• 總浮時（Total Float, $TF$）公式： $TF = LS - ES = LF - EF$
• 當活動符合 $LS - ES = 0$（或 $LF - EF = 0$）時，即為要徑活動。

解題方法

判定活動是否位於要徑上，關鍵在於計算其「總浮時（Total Float）」。

1. 透過網圖順推得出各項活動的 $ES$ 與 $EF$；再由專案終點逆推得出各項活動的 $LF$ 與 $LS$。
2. 比對各活動的開始時間差或結束時間差：

• 活動之最晚開始時間減去最早開始時間（$LS - ES$）即為該活動擁有的時程彈性（浮時）。
• 當 $LS - ES = 0$（無任何寬裕延誤空間）時，該活動即屬於要徑活動。

3. 由各個浮時為零的活動依序串聯，即構成專案由開始到完工的「要徑」。因此，要徑活動正是藉由比對「最早開始時間（$ES$）」與「最晚開始時間（$LS$）」計算得出。

選項分析

• (A) 錯誤：此為專案管理最具代表性的名詞陷阱。「要徑」在專案管理學中是「時間跨度最長、時程最緊縮」的路徑，要徑上的活動延遲會直接導致專案延期；但非要徑活動可能承載專案的核心技術或關鍵風險（例如資安防護、核心模組架構），不能因此認定要徑是「最重要」的路徑。

核心觀念

專案計畫書（Project Plan）會說明專案如何執行與管理。里程碑（milestone）​是專案時程中的重要檢核點，通常代表重大階段、交付成果或關鍵事件的預定完成時間。里程碑本身不一定包含工作期間，也不直接代表預算或風險事項。

解題方法

題目問的是專案計畫書哪一部分會定義「里程碑」。判斷時先看里程碑的功能：它用來標示專案進度中的重要時間點，因此應歸在描述各項活動與時間安排的專案時程。

選項分析

• (A) 工作條款：錯誤。​工作條款（Statement of Work）主要說明專案要完成的工作範圍、需求與交付內容；里程碑是時程管理項目。
• (B) 專案時程：正確。​專案時程安排活動的先後、起迄時間與重要檢核點，里程碑的定義與日期通常在此呈現。
• **(C) 預算規劃：錯誤。

核心觀念

工作分解結構（WBS）是以階層方式呈現專案全部工作範圍的工具，將專案所需的交付成果與相關工作，分解至可估算、可指派及可控制的「工作包」。

建立 WBS 可採用自上而下法、自下而上法及類比法等方法。本題的判斷關鍵是「新產品專案」：既有經驗與分解架構較少，適合先由團隊提出具體工作，再逐層整合，因此選擇自下而上法。

解題方法

新產品專案通常缺乏成熟的工作架構，團隊成員可先從各自的專業出發，辨認必須完成的具體工作，再依成果或功能分群，向上彙整成完整的 WBS。

例如開發新型資訊產品，可先列出需求訪談、介面設計、資料庫設計、程式撰寫及測試等工作，再整合為需求分析、系統設計、系統開發及系統驗證等較高層級項目。

其建立方向為：

具體工作項目 → 分群整合 → 上層交付成果 → 完整專案架構。

這正是自下而上法的特色。

選項分析

• (A) 自上而下法：錯誤。 從專案整體目標與主要交付成果開始，逐層向下細分。適合整體架構較明確、團隊對工作內容較熟悉的情況；本題強調新產品，較符合先辨識具體工作再向上整合的方式。

• (B) 類比法：錯誤。 參考過去相似專案的 WBS，再依本次需求調整。使用前提是具有可供比較的既有專案；新產品的先例與可參考資料較少，因此不是本題的最佳選擇。

核心觀念

本題考查專案經理的關鍵能力。專案經理須整合團隊、資源與利害關係人，使專案目標得以達成；其中，溝通能力是協調工作、傳遞資訊及處理利害關係人需求的基礎。專案經理需要讓團隊理解目標與分工，也要掌握進度、風險及問題，並促成各方合作。

解題方法

題目問「最重要的能力」，判斷重點在於哪項能力能貫穿專案各階段、連結團隊與利害關係人。專案經理雖須具備技術理解、談判及團隊建立能力，但這些工作都仰賴有效溝通來完成，因此選擇「溝通」。

選項分析

• (A) 團隊建立：​重要能力之一，有助於形成合作團隊、提升凝聚力；但它是專案管理工作的一環，溝通則廣泛支援團隊建立及其他管理活動。
• (B) 談判：​有助於處理資源、時程或需求上的歧見，但通常在特定情境中發揮作用，涵蓋面不如溝通。
• (C) 溝通：​正確。

核心觀念

「低價拉標」（Buy In）是廠商為取得合約，先以低於合理水準的價格投標，甚至低估成本或報價，再於專案開始後，透過重新協商、變更範圍或其他方式，爭取補足原先低報的費用。其關鍵在於「先以低價取得合約，再設法回收低報的成本」。

解題方法

題目問的是 Buy In 的定義。辨認時抓住兩個階段：

1. 投標階段：廠商為提高得標機會而低報價格或低估成本。
2. 履約階段：廠商再針對成本較高的部分要求調整、重新協商或追加費用。

符合這兩階段特徵的敘述，就是「低價拉標」。

選項分析

• (A) 錯誤：這描述的是成本高估，導致投標價格缺乏競爭力而失去得標機會，與 Buy In 的低報方向相反。

核心觀念

本題考的是專案利害關係人管理中，利害關係人影響力隨專案時程變化的關係。依 PMBOK 所述的影響力曲線，利害關係人對專案產出特性（範圍、功能、品質）與最終成本的影響力，在專案初期最大，之後隨專案推進而遞減。與此相反，變更成本（cost of change）則隨時間遞增。兩條曲線方向相反，是本題的核心。

原因在於：專案初期的範圍、需求、目標、技術方案、預算與資源配置尚未定案，利害關係人的意見仍能決定方向。進入中後期後，基準（baseline）已建立，變更必須經過變更控制程序，且已完成的工作可能需要返工，成本隨之升高。

解題方法

本題屬概念題，不需計算。切入點是判斷「尚未做出的決策有多少」：專案越早期，待定的決策越多，每一項決策對最終特性與成本的影響越大，因此利害關係人的影響力最大。反過來，專案越晚期，可調整的空間越小。依此邏輯即可選出 (A)。

選項分析

(A) 正確。 專案初期範圍與需求尚未凍結，利害關係人的需求、期望與決策可直接塑造專案的功能與架構，對最終特性與成本的影響力最大，這也是規劃階段必須投入大量利害關係人溝通與需求確認的原因。

(B) 錯誤。 利害關係人正是專案需求、驗收標準與資金的來源，與專案最終特性及成本有直接關係，故「沒有直接關係」不成立。

核心觀念

本題考查專案的形成因素。專案管理常見的專案啟動原因包括：市場需求、組織需求、顧客要求、技術進步、法律或法規要求，以及社會需求等。這些因素會促使組織投入資源，完成具有明確目標與期限的工作。

解題方法

逐一判斷各選項是否屬於促成專案形成的外部或組織需求。市場、法規與技術變化，都是常見的專案觸發因素；人事異動本身通常只是組織內部的人員變化，並非專案形成的典型因素，因此選出該項。

選項分析

• (A) 市場的需求：​是。市場需求可能促使組織開發新產品、改善服務或調整營運流程，因而形成專案。
• (B) 人事的異動：​不是。人員調職、離職或職務更替屬於人力資源變動，通常不會單獨構成專案形成因素。
• (C) 法律的規定：​是。

核心觀念

本題考查「矩陣式組織」的權責分工。矩陣式組織結合功能式組織與專案式組織的特性，由專案經理與功能部門經理共同管理專案資源，成員通常同時接受兩者的指揮，因此具有雙重權責關係。

兩類經理的主要分工如下：

• 專案經理：負責跨部門整合，協調專案的範疇、時程、成本與交付成果。
• 功能部門經理：負責專業技術、人員配置、技術諮詢及功能領域的支援。

矩陣式組織依專案經理的權限大小，可分為弱矩陣、平衡矩陣及強矩陣。因此，不能一概認定矩陣式組織中的專案經理具有較高權力。

解題方法

題目要求選出「錯誤敘述」，判斷重點是：該敘述是否為矩陣式組織的一般特徵，還是只適用於特定類型。

技術支援、跨功能資源整合，以及兩類經理間的協調，均符合矩陣式組織的運作方式；「專案經理有較高的權力」則須視矩陣類型而定，不能直接視為共同特徵。

選項分析

(A) 正確。 部門經理掌握所屬功能領域的專業知識與人力，須提供專案所需的技術協商、諮詢及支援，確保專案獲得適當的專業資源。

(B) 錯誤。 專案經理的權力並非在所有矩陣式組織中都較高：

• 弱矩陣：功能部門經理較具主導權，專案經理的權限有限，偏重協調。
• 平衡矩陣：專案經理與功能部門經理分享管理權責。
• 強矩陣：專案經理具有較大的權限，組織運作較接近專案式組織。

核心觀念

專案是為達成特定目標而設立的臨時性工作，具有明確的起訖時間，並在有限資源下完成具特殊性或獨特性的任務。專案中的工作通常彼此相互關聯，需要協調與整合；不同利害關係人也可能因目標或資源分配而產生利益衝突。

解題方法

判斷各選項是否符合專案特性，重點看兩件事：專案工作是否受到資源與時間限制，以及各項任務是否為完成共同目標而彼此關聯。若某選項把專案描述成彼此獨立，就與專案需要整合、協調的特性不符。

選項分析

• (A) 資源的有限性：正確。 專案受預算、人力、設備與時間等資源限制，必須在有限條件下完成。
• (B) 任務的特殊性：正確。 專案通常為特定目標設計，具有獨特性，不只是例行、反覆執行的日常作業。
• **(C) 利益的衝突性：正確。

核心觀念

專案金三角（Triple Constraint）是專案管理的基本架構，包含 範疇（Scope）、時間（Time）​與成本（Cost）。三者彼此牽制：擴大範疇可能需要更多時間或成本；縮短時程可能增加成本，或必須調整交付範圍；降低成本也可能影響時程或範疇。

解題方法

辨認題幹中的「三個基本因素」「彼此相互牽制」及「專案金三角」，直接對應範疇、時間、成本三項。題目列出四個選項，其中「組織」不是傳統專案金三角的構成因素。

選項分析

• (A) 組織：錯誤。 組織會影響專案的治理、溝通與資源配置，但不屬於傳統專案金三角的三項因素。
• (B) 範疇：正確。 範疇界定專案要完成的工作與交付成果。
• **(C) 時間：正確。

核心觀念

1. 專案時程壓縮（Schedule Compression）： 在不縮減專案範疇（Scope）的前提下，為滿足專案交付期限、強加日期（Imposed Dates）或商業目標，所採取的縮短或加速專案時程技術。主要包含兩種方法：

• 趕工（Crashing）：藉由增加額外資源（如加班、增聘人力、外包）以增加成本為代價來換取時間，通常針對關鍵路徑（Critical Path）上成本效益最高的工作。
• 快速跟進（Fast Tracking）：將原本應循序進行的活動改為平行或部分重疊進行，以承擔重工與專案風險為代價換取時間。

2. 時程壓縮的驅動動機（Business Drivers）： 在軟體工程與資訊系統專案管理（如 Pressman 理論體系）中，專案時程壓縮最常源於商業競爭壓力。資訊產品與系統具備極高的時效性，及早推出產品（Time to Market, TTM）以掌握「市場機會之窗（Market Window）」、建立先動優勢（First-Mover Advantage）並搶佔市佔率，是組織主動要求壓縮時程最普遍且關鍵的策略原因。

解題方法

本題考查專案管理實務中「時程壓縮」的核心策略目的：

1. 區分「主動策略」與「被動補救」： 專案時程壓縮固然可能發生於專案進度落後時的追趕，但專案管理理論強調時程基準（Schedule Baseline）之所以在規劃或執行階段被嚴格壓縮，絕大多數是為了配合組織的商業策略——縮短產品上市週期以對抗競品。
2. 切入產品生命週期與市場價值： 軟體或資訊系統若延遲進入市場，即便功能完整，也可能失去競爭力或被對手瓜分市場份額。因此，「爭取市場先機、市佔率」是推動專案團隊不惜投入額外成本（Crashing）或承擔重工風險（Fast Tracking）以壓縮時程的最主要動因。

選項分析

• (A) 爭取市場先機、市佔率：【正確】 在高度競爭的商業與科技環境中，「上市時間」（Time to Market）往往決定專案與產品的成敗。為了趕在競爭對手推出類似系統前上市、掌握特定市場機會之窗，專案發起人或高層主管通常會給定極具挑戰性的壓縮期限，促成專案時程壓縮的實施。
• (B) 因應使用者時程需求：【錯誤】

核心觀念

本題考「軟體專案的關鍵成功因素」，重點在專案是否達成預定目標，以及由誰判定專案成敗。專案成果須由利害關係人依事先約定的成功準則評估；諮詢小組可以提供建議，但不是當然的最終判定者。

專案常見的衡量面向包括需求與品質、成本、時程及效益。合約要求與需求規格都可能是專案必須遵守的條件，但題目問的是關鍵成功因素，須辨認哪個選項不只是執行條件，而是把成敗判定權交給特定小組。

解題方法

逐項區分「專案要達成的條件」與「誰負責判定成敗」。軟體專案通常須遵守合約、符合需求規格，並考量成本效益；然而，專案成敗應依事先設定的目標與評估準則判定，不能僅因某個諮詢小組作出判斷，就把它視為通用的關鍵成功因素。

選項分析

• (A) 必須滿足合約的要求：錯誤。 滿足合約要求是專案執行的重要約束與交付條件，但單獨滿足合約不必然代表專案整體成功；仍須看專案目標及其他成功準則。
• (B) 必須符合需求規格：錯誤。 符合需求規格是軟體產品驗收的重要條件，但專案成功還涉及成本、時程、品質與效益等面向，不能只以此作為完整的關鍵成功因素。
• **(C) 必須符合成本效益：正確。

核心觀念

本題考查資訊系統專案評估中的「有形效益」與「無形效益」。分類重點是效益能否具體衡量，並合理換算為成本節省、收入增加或資源運用的改善，與是否具有實體形狀無關。

• 有形效益：可透過作業時間、處理件數、人力成本、資源使用情形等資料具體衡量。例如縮短訂單處理時間、降低作業成本。
• 無形效益：主要表現在感受、服務品質、商譽或組織形象，較難直接換算為金錢。例如提升使用者滿意度、改善企業形象。

解題方法

逐項判斷效益的直接表現：若是作業效率或資源利用的改善，歸入有形效益；若是使用者感受或外界對企業評價的提升，歸入無形效益。

判斷時應以選項所描述的效益本身為準，不必延伸推算其日後帶來的營收。

選項分析

• （A）提升訂單處理效率：屬於有形效益，不選。 可用每筆訂單的處理時間、每小時處理件數或所需人力衡量。例如處理時間縮短，可進一步估算節省的工時與人事成本，具有具體的量化基礎。

• （B）提升系統使用率：本題歸為有形效益，不選。 系統使用率可透過使用人數、使用次數或使用時間等紀錄衡量，反映既有系統資源的利用程度。使用率提升，有助於發揮已投入的設備與開發成本效益，因此本題將其列為可具體衡量的資源運用效益。

核心觀念

本題考查專案管理的五大流程群。依《專案管理知識體系指南》（PMBOK），五大流程群為：

1. 啟動流程群（Initiating）
2. 規劃流程群（Planning）
3. 執行流程群（Executing）
4. 監控流程群（Monitoring and Controlling）
5. 結束流程群（Closing）

流程群是依專案管理活動的功能分類；它們不一定按固定順序各執行一次，專案進行中也可能反覆進行。

解題方法

逐一比對選項與五大流程群的正式名稱。選項中的「啟動流程群」及「監控流程群」都屬於五大流程群；「導入流程群」不是正式名稱，而「結案流程群」也不是標準稱呼，正式名稱為「結束流程群」。

選項分析

• (A) 啟動流程群：正確。 五大流程群之一，主要確認專案或階段獲得授權，並界定初步目標與利害關係人。
• (B) 導入流程群：錯誤。 五大流程群中沒有「導入流程群」；

核心觀念

本題考「白箱測試」與「黑箱測試」的差異，以及兩者常見的測試階段。

• 白箱測試（White-box testing）：依據程式內部的程式碼、控制流程與邏輯設計測試，著重檢查程式內部結構是否正確，常見於單元測試。
• 黑箱測試（Black-box testing）：不檢視程式內部實作，從輸入與輸出及外部功能需求設計測試，著重確認系統是否符合規格，常見於驗收測試。

解題方法

先辨認各選項所描述的是測試「廣度或深度」，還是測試「階段」。

白箱測試需要掌握程式內部邏輯，適合在測試單一模組或程式單元時檢查路徑與條件，因此與單元測試的關聯較強。黑箱測試則以功能需求及外部行為為判斷依據，常用於確認完成的系統是否符合使用者需求，因此與驗收測試的關聯較強。

選項分析

• (A)「白箱測試」以測試廣度為主：錯誤。​白箱測試聚焦於程式內部邏輯與結構，重點是檢查程式路徑、分支與條件等，不宜概括為以測試廣度為主。
• **(B)「黑箱測試」以測試深度為主：錯誤。

核心觀念

本題考查雲端運算（Cloud Computing）​三大服務模型中的軟體即服務（Software as a Service，SaaS）​及其在系統專案管理中的營運與採購特性。

1. 雲端運算三大服務模型（依 NIST SP 800-145 標準分層）：

• 基礎架構即服務（IaaS）：供應商提供處理能力、儲存空間、網路等底層運算資源，使用者可自行佈署及執行任意作業系統與軟體。核心特徵在於底層的「資源共享池化（Resource Pooling）」與「快速彈性佈署（Rapid Elasticity）」。
• 平台即服務（PaaS）：供應商提供應用程式開發、測試、佈署與執行的平台環境（如資料庫引擎、開發中介軟體、Runtime）。
• 軟體即服務（SaaS）：供應商將完整的應用軟體託管於雲端基礎架構上，終端使用者無須在本地端安裝與維護軟體，直接透過網際網路（通常為網頁瀏覽器或輕量級用戶端）存取使用。

2. SaaS 在專案管理中的成本與交付特徵：

• 授權模式的轉變：傳統套裝軟體採「一次性買斷（Perpetual License）」，專案初期須投入龐大的資本支出（CapEx），並承擔後續伺服器維護與升級合約成本。
• 隨選計價（Pay-as-you-go / On-Demand Pricing）：SaaS 採訂閱制（Subscription-based），專案組織可依實際使用人數（Per Seat）、使用量或租用時間精準付費，將大額固定成本轉化為彈性營運支出（OpEx），隨專案規模成長或縮減授權。

解題方法

從「系統專案管理」的角度出發，評估引進資訊系統的評選標準與交付模式：

• 辨別服務層次與受眾視角：
• 若考點為系統架構師或維運工程師對運算資源、虛擬機的自動擴展與動態配置，主要歸屬於 IaaS 與 PaaS 的技術特徵（如資源共享、彈性佈署）。
• 若考點為終端組織或專案經理在採購軟體應用服務時的本質特徵，最顯著且具代表性的是商業交付與收費機制（隨選計價）。
• 排除非典型特性：SaaS 軟體普遍由各商業廠商專利封閉持有，通常具備「廠商鎖定（Vendor Lock-in）」風險，而非基於開放標準。因此，四個選項中專屬於 SaaS 最核心的特徵即為「隨選計價」。

選項分析

• (A) 開放的標準：錯誤。 多數 SaaS 應用軟體（例如 Salesforce、Microsoft 365 等）皆為軟體開發商所擁有的專利封閉架構（Proprietary Systems）。其內部程式碼、專屬資料格式與底層系統並不公開，不同廠商間的系統往往難以無縫遷移，容易產生「廠商鎖定（Vendor Lock-in）」現象，因此「開放的標準」並非 SaaS 的代表性特徵。
• (B) 隨選計價：正確。 SaaS 最大的經濟效益與商業特性在於打破傳統軟體龐大的前期授權費與硬體建置成本，改採「按需付費（Pay-as-you-go）」或「訂閱制（Subscription Model）」。企業在專案進行時，可隨時依據使用人數、模組需求或使用頻率隨選彈性調整費用，完全符合 SaaS 的定義。
• (C) 彈性佈署：錯誤。

核心觀念

本題考查敏捷專案管理（Agile Project Management, APM）的適用情境與團隊運作方式。敏捷方法採取短週期、反覆交付、持續取得回饋並調整計畫的作法，適合需求持續變動、初期難以完整界定範疇的專案。

常見的敏捷開發週期約為數週；團隊在每個週期內選定工作項目、完成並檢視成果，再依回饋規劃下一輪。敏捷並非由專案經理單方面分派所有工作，而是重視團隊協作與自我管理。

解題方法

判斷各選項是否符合敏捷管理的特徵：專案是否適合短週期迭代、是否能因應範疇或需求變動，以及工作安排是否仰賴團隊共同協作。敏捷並不以「專案小型」作為必要條件，也不要求預先精確估出整體成本與時程。

選項分析

(A) 適用在小型工作專案，通常將專案分成若干 2 至 4 週的期間來執行：錯誤。 將工作切分成約 2 至 4 週的短週期，符合敏捷迭代的特徵；但敏捷不以「小型工作專案」為適用範圍的限制。其主要適用依據是需求變動、需要頻繁回饋與逐步交付，而非專案規模。因此此選項把正確的週期描述與錯誤的適用範圍限制併在一起。

(B) 適用在無法準確定義範疇的系統：正確。 當專案初期無法完整、準確地界定範疇或需求時，敏捷可透過短週期交付成果、蒐集利害關係人回饋，再逐步調整待辦事項與後續工作。因此它適合需求尚未明確，或會隨環境與使用者回饋持續變動的系統。

核心觀念

本題考查專案文件管理的常見問題。專案文件製作不只包含撰寫內容，也涵蓋文件的儲存、修訂、審核、發布與歸檔。管理重點在於確保團隊能找到需要的文件、使用正確版本、追溯處理歷程，並確認內容完整。

因此，集中管理、版本控制、生命週期紀錄及完整性，都是專案文件製作與管理時必須處理的課題。

解題方法

以「文件從建立到歸檔，會遇到哪些管理問題」逐項判斷：

• 文件存放在哪裡？​涉及集中管理。
• 目前應使用哪一版？​涉及版本控制。
• 文件經過哪些處理程序？​涉及生命週期紀錄。
• 應有的文件及內容是否齊全？​涉及完整性。

題目問「哪幾項」，各選項應獨立判斷，不能預設只有一個正確答案。

選項分析

（A）如何集中管理專案文件資訊：正確。 專案文件若分散在個人電腦、電子郵件與不同資料夾，容易造成搜尋困難、重複保存及資訊不同步。透過共用文件庫、統一分類與存取權限，可協助成員取得所需資訊，因此集中管理是常見問題。

（B）如何控制文件版本：正確。 需求規格書、設計文件及測試計畫會隨專案進展修訂。若缺乏版本編號、修訂紀錄與核准機制，成員容易誤用舊版，造成開發或驗收依據不一致。因此，版本控制是文件管理的重要課題。

核心觀念

本題考「專案終結（結案）型態」的分類。常見分類包含專案取消、專案停滯、專案終止與專案結束；題目問的是「哪幾項是專案終結的型態之一」，因此要辨認各選項是否屬於這組分類。

解題方法

逐一核對四個選項是否為專案終結型態的名稱。這裡的「專案結束」指完成原定目標後結束；「專案取消」則是專案尚未完成便決定停止。專案停滯與專案終止也都是專案結束過程中可能出現的型態。

選項分析

• (A) 專案取消：正確。 專案尚未完成時，因可行性不足、目標改變或其他決策而取消，屬於專案終結型態。
• (B) 專案停滯：正確。 專案因資源、決策或執行問題而停擺，進度無法推進，是專案終結型態之一。
• **(C) 專案終止：正確。

核心觀念

專案績效指標用來評估專案目標的達成程度，應能清楚說明評量內容，並以可取得的資料檢視成果。好的指標通常具備明確性、可衡量性與可驗證性；可預測性則不是績效指標的基本特性。

解題方法

逐一判斷各選項是否有助於讓指標定義清楚、能衡量成果，或能用客觀資料核實。若某項特性只描述預測未來的能力，就不屬於績效指標本身的必要條件。

選項分析

• (A) 可驗證性：正確。 指標的資料來源與判定方式應可查證，使不同人依據相同資料能核對評量結果。
• (B) 明確性：正確。 指標應清楚界定衡量對象與範圍，避免解讀不一，才能據以管理與比較。
• **(C) 可衡量性：正確。

核心觀念

• 績效衡量基準（Performance Measurement Baseline）：由範圍基準、進度基準與成本基準整合而成，是監控專案時衡量實際績效的標準。
• 掙值管理（Earned Value Management, EVM）三要素
• PV（計畫值，Planned Value）：依基準，到某時點應完成工作的預算成本。
• EV（掙得值，Earned Value）：到某時點實際完成工作，依基準計算的預算價值。
• AC（實際成本，Actual Cost）：到某時點實際已投入的成本。
• 與基準比較的兩項核心變異
• 進度差異：$SV = EV - PV$
• 成本差異：$CV = EV - AC$
• 正值表示超前或節省，負值表示落後或超支。

解題方法

題幹的關鍵字是「與專案基準比較」與「差異分析」。掙值管理中，直接由基準數據與實際數據相減而得的變異只有 SV 與 CV，因此差異分析的焦點是成本與時程。其餘選項分屬績效報告的其他內容（原因分析、預測），不屬於基準差異本身。

計算示例：假設 BAC = 100 萬，目前時點 PV = 60 萬、EV = 50 萬、AC = 55 萬。

$SV = 50 - 60 = -10 \text{（萬，進度落後）}$

$CV = 50 - 55 = -5 \text{（萬，成本超支）}$

$SPI = \frac{EV}{PV} = \frac{50}{60} \approx 0.83, \qquad CPI = \frac{EV}{AC} = \frac{50}{55} \approx 0.91$

選項分析

• (A) 問題分析：錯誤。 問題分析（原因分析）是找出偏差成因，並規劃矯正與預防措施。它發生在變異被辨識之後，是績效報告的內容之一，但不是與基準比較後產生的差異項目。
• **(B) 未來預測：錯誤。

核心觀念

專案生命週期（Project Life Cycle, PLC）是專案從構想到完成，依序劃分階段的管理架構。常見的階段包括概念、發展、執行與結束；各階段會產生供管理者檢視的工作成果，並據以決定是否進入下一階段。

「可交付標的」（deliverable）是階段完成時產出的具體成果，必須可辨識、可驗證。它可以是有形的，也可以是無形的；例如軟體、報告、設計文件都能成為可交付標的。

解題方法

逐項辨認選項是否符合 PLC 的階段安排與可交付標的定義。判斷時要分清楚兩件事：階段結束時可能設有審查與決策機制，但這不代表每個階段一律都有名為「封殺點」的固定決策點；另外，「可驗證」也不等於「必須是實體物品」。

選項分析

(A) 錯誤。 階段結束時通常會進行階段審查或決策，以判斷是否進入下一階段；但並非每個階段結束都必然設有一個「Decision Point、Kill Point」。Kill Point 指的是在審查後決定停止專案的可能關卡，不是每階段固定設置的同義名稱。

核心觀念

本題考「專案管理」的共同特性。專案是為達成特定目標而進行的工作，通常具有明確的起訖時間與獨特成果；它與持續、重複的日常營運工作不同。專案管理則是透過計畫、執行與控制等過程，運用人力及有限資源完成專案目標。

解題方法

逐項判斷選項是否描述專案管理的普遍特性：

• 專案需要人員參與才能完成。
• 專案受時間、經費、人力等資源限制。
• 專案工作具有暫時性與獨特性，不是持續重複的日常工作。
• 專案管理須經由計畫、執行與控制等管理過程推進。

選項分析

(A) 均是靠人來完成的：正確。 專案由人員組成團隊，運用各自的專業與分工完成工作；即使使用工具或自動化技術，仍需有人規劃、管理或執行相關工作。

(B) 均受到有限資源的限制：正確。 專案須在有限的時間、經費、人力與設備等條件下完成。資源限制是專案管理需要規劃與控制的重要原因。

核心觀念

本題考「專案管理計畫書」在專案變更控制中的作用。專案管理計畫書是整合專案各項管理計畫與基準的文件，說明專案如何執行、監控及控制。進行變更控制時，必須依據已核准的基準與既定程序，評估變更對專案的影響並決定是否核准。

解題方法

先辨認題幹的關鍵詞「變更控制」。變更控制需要兩類依據：一是判斷變更影響的控制基準，二是處理變更的程序與方法。題目問的是「專案管理計畫書」對變更控制的重要性，選項中以「提供專案控制的基準」最符合其核心功能。

選項分析

• (A) 提供專案成效的資訊：錯誤。 專案成效資訊主要來自工作績效資料、工作績效資訊及績效報告，用於了解實際執行狀況；這不是專案管理計畫書在變更控制中的主要作用。
• (B) 提供專案進度評量：錯誤。 進度評量須比較實際進度與核准的進度基準。計畫書可包含進度管理計畫與進度基準，但題目所問的是其對變更控制的整體重要性，核心在提供控制基準，而非單獨提供進度評量。
• (C) 提供專案控制的基準：正確。 專案管理計畫書包含範疇、時程、成本等基準。