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

核心觀念

專案工作或管理計畫書（Project Management Plan）是整合各項專案子計畫的基準文件，說明專案要完成什麼、由誰負責、何時完成、如何配置資源，以及如何管理風險與品質。它作為專案執行、監控、變更控制與結案的共同依據。

本題是計畫書目錄設計題，重點不在背誦唯一固定格式，而在於完整涵蓋軟體開發專案的管理面向，並呈現各面向如何形成可執行、可追蹤的計畫。不同組織的文件名稱及章節安排可以不同，但內容應能對應專案生命週期與管理需求。

解題方法

可從「專案如何啟動、規劃、執行、監控，最後結案」的脈絡安排目錄，再逐一檢查是否涵蓋範疇、時程、成本、品質、資源、溝通、風險、採購及變更等管理領域。軟體專案另須明確納入需求、開發方法、測試、部署、組態與維護等內容，讓計畫書不只是行政管理清單，也能指引軟體產品的產出。

建議目錄

1. 計畫書概述

• 計畫書目的、適用範圍、使用對象
• 專案背景、目標與成功標準
• 名詞、縮寫、參考文件及文件修訂紀錄

2. 專案概況與治理

• 專案範圍摘要、主要交付成果
• 專案組織架構、角色與權責
• 決策、審查、核准及升級處理機制
• 利害關係人清單與需求摘要

3. 範疇與需求管理計畫

• 產品及專案範疇、明確排除事項
• 需求蒐集、分析、確認、追蹤與變更流程
• 工作分解結構（WBS）、工作套件及驗收條件
• 需求與交付成果的追溯方式

4. 軟體開發與技術管理計畫

• 開發生命週期與方法，例如循序式或敏捷式
• 系統架構、技術選型、開發環境與工具
• 設計、程式撰寫、程式碼審查及整合方式
• 技術文件、技術決策及技術債管理

5. 時程管理計畫

• 活動定義、相依關係與估算方式
• 里程碑、專案時程基準及排程工具
• 進度追蹤、落後處理與時程變更程序

6. 成本與預算管理計畫

• 人力、設備、軟體、採購及其他成本估算
• 預算基準、預備金及成本核准方式
• 成本追蹤、差異分析與預算變更流程

7. 人力與資源管理計畫

• 人員需求、職務分工與責任指派
• 資源取得、訓練、工作負荷與替補安排
• 設備、軟體工具及開發環境等資源配置

8. 品質管理與測試計畫

• 品質目標、標準、指標及審查方式
• 測試策略與測試層級，例如單元、整合、系統及驗收測試
• 缺陷通報、分級、修正、回歸測試與品質驗收
• 測試環境、測試資料及測試紀錄管理

核心觀念

**Cone of Uncertainty（不確定性錐）**說明軟體專案在生命週期早期，需求、範圍、技術方案與執行方式尚未明朗，因此成本與時程估算的誤差範圍較大；隨著需求逐步釐清、設計與實作資訊累積，不確定性會逐漸縮小，估算也更可靠。

常見的示意方式是以需求確立時的最佳估算為基準，早期實際成本可能落在估算值的約 $0.25$ 至 $4$ 倍範圍內；專案進展後，範圍逐步收斂。這是概念示意，不是適用於所有專案的固定公式。錐體描述的是估算的不確定性，不代表成本必然隨時間下降，也不保證每個專案都以相同速度收斂。

解題方法：依階段選擇估算方法

作答時，先指出「階段越早，資訊越少，宜採粗略、類比或範圍估算；資訊越完整，宜採較細緻、由下而上的估算」，再將此原則套用到生命週期各階段。估算方法須與當時可取得的資訊相配，並隨專案進展更新。

生命週期階段	估算特性與適用方法
概念／可行性階段	需求與範圍尚粗略，估算不確定性最高。可採專家判斷、類比估算，參考過去相似專案；以區間或情境呈現結果，並明列假設與風險。此時不宜把單一數字當成精確承諾。
需求分析與規劃階段	需求逐步具體化，可依功能規模採功能點估算，再套用歷史生產力與成本資料；也可用參數模型，依規模、複雜度等因素推估。以區間估算保留尚未釐清的需求變動。
架構與設計階段	系統結構及子系統較明確，可將工作拆成子系統、模組或工作包，採由上而下估算掌握整體，再以由下而上估算細項並彙總；可用三點估算納入樂觀、最可能、悲觀情境。

核心觀念

**Stacey Matrix（Stacey 矩陣）**是依據專案中「需求的確定程度」與「解決方案或技術的確定程度」，判斷專案所處的複雜度，進而選擇合適的管理方式與開發流程。它的核心觀念是：專案越可預測，越適合事先規劃並依序執行；不確定性越高，越需要透過反覆驗證、協作與調整來推進。

矩陣的兩個主要維度為：

• 需求（What）的確定程度：使用者要解決的問題、功能範圍與驗收條件是否清楚、穩定。
• 解決方案（How）的確定程度：技術、架構、工具與實作方式是否成熟，能否可靠地預測成果。

兩個維度都明確時，專案較可預測；需求或技術越不確定，專案的複雜度與風險越高。Stacey 矩陣常將情境概分為簡單、複雜、混亂等區域；不同版本對區域名稱與邊界的標示略有差異，應以「確定程度」判斷管理方式，而非僅依區域名稱套用流程。

解題方法

本題要把「專案類型」連結到「需求與技術的不確定程度」，再由此推導開發方法與流程模式。作答可依下列順序：

1. 判斷需求是否明確、穩定。
2. 判斷技術與解決方案是否成熟、可預測。
3. 依兩者的確定程度選擇流程：越確定，越適合預先規劃；越不確定，越適合短週期回饋與逐步調整。
4. 說明流程選擇仍須考量法規、風險、團隊能力、利害關係人參與及交付限制。

依專案類型選擇開發方法與流程

專案情境	需求與技術特徵	適合的方法與流程
需求明確、技術成熟	功能、介面、規格及驗收條件清楚；採用成熟技術，變更少且成果可預測	適合計畫驅動方法，例如瀑布式或階段式流程。先完成需求與設計，再依序進入開發、測試及部署；以基準計畫、文件與階段審查控管進度和品質。
需求大致清楚，但細節需要逐步確認	整體目標明確，部分功能或優先順序會隨使用者回饋調整；技術大致成熟	適合增量式或迭代式流程。先切分可交付功能，分批開發與驗收；每一輪依回饋調整後續需求與優先順序。
需求持續變動，或使用者需藉由操作原型釐清需求	需求無法在初期完整定義，價值取決於持續回饋；

核心觀念

本題考《政府採購法》的決標原則，以及機關在採購需求不能只用價格衡量時，如何透過評選選出最適合的廠商。以下法規說明以命題當年（民國 112 年）法規為準。

依《政府採購法》第 52 條，機關辦理採購，原則上採最低標決標；如依招標文件規定，以綜合評選方式評定最有利標，則依同條第 1 項第 3 款辦理。兩者重點如下：

• 最低標：在符合招標文件規定的合格廠商中，以標價最低者為得標廠商。核心判斷是「符合規格與資格後，比價格」。
• 最有利標：依招標文件預先訂定的評選項目與標準，綜合比較廠商投標內容，評定最符合機關需求者為得標廠商。評選可考量技術、品質、功能、商業條款及價格等項目，價格不必然是唯一或最重要的因素。

解題方法

作答時依序處理三件事：

1. 先定義兩種決標原則：說明最低標以合格廠商的最低價格決標；最有利標依事先公告的標準綜合評選。
2. 再列適用最有利標的法定情形：分辨依《政府採購法》第 22 條辦理的特定採購，以及依第 56 條辦理的公開評選決標。
3. 最後說明評選程序的控制重點：招標文件先寫清楚評選規則，委員依同一標準評選，過程留有紀錄，避免事後更改標準或不當影響結果。

何謂最低標與最有利標

最低標

最低標是指機關先確認投標廠商及其標的符合招標文件的資格、規格與其他要求，再由合格廠商中選擇標價最低者決標。若最低標廠商不符合招標文件，不能只因價格最低就決標。

最有利標

最有利標是指機關依招標文件所列的評選項目及評審標準，綜合評選投標內容，決定整體條件最符合機關需求的廠商。依《政府採購法》第 56 條，評選可採序位法或計數法；價格得列為評選項目，也得作為決標標準之一。未列入招標文件的項目，不得在評選時另行拿來比較。

因此，最有利標不是「價格不重要」，而是機關可依採購需求，同時衡量品質、技術、功能、履約能力與價格等因素。

何種情況下得採最有利標評選方式

依《政府採購法》第 22 條辦理的採購

符合《政府採購法》第 22 條第 1 項所列限制性招標情形，並依法辦理評選者，可採最有利標精神評選。與本題委外開發軟體最相關的是第 9 款：委託專業服務、技術服務、資訊服務或社會福利服務，經公開客觀評選為優勝者。

委外開發應用軟體通常涉及需求分析、系統設計、技術方案、資安、整合及後續維護等專業判斷；若符合相關法定要件，機關得依資訊服務評選及計費規範辦理評選，選擇最符合需求的廠商。

依《政府採購法》第 56 條採最有利標決標