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

核心觀念

本題評估委外資訊系統投資的可行性，核心在於專案財務可行性分析中的成本效益分析（Cost-Benefit Analysis, CBA）與淨現值法（Net Present Value, NPV）。

1. 貨幣時間價值（Time Value of Money）： 未來收支之名目金額（面值）不能直接相加，必須考慮通貨膨脹與資金機會成本，透過折現率（Discount Rate）折算回基期（第 0 年）的價值。
2. 現值（Present Value, PV）計算公式： $PV = \frac{FV}{(1 + r)^t}$

• $FV$（Future Value）：第 $t$ 年之未來值（面值）。
• $r$：折現率（本題通膨率為 $10\% = 0.1$）。
• $t$：期數（年份，$t = 0, 1, 2$）。

3. 淨現值（Net Present Value, NPV）定義與決策準則： $NPV = \sum_{t=0}^{n} \frac{B_t - C_t}{(1 + r)^t} = PV(\text{總收益}) - PV(\text{總成本})$

• $B_t$：第 $t$ 年收益；$C_t$：第 $t$ 年成本。
• 決策準則：
• 若 $NPV > 0$：表示該投資帶來的超額報酬大於資金成本，具投資可行性（接受專案）。
• 若 $NPV = 0$：損益兩平。
• 若 $NPV < 0$：表示實質收益無法彌補成本與資金折現損失，不具投資可行性（拒絕專案）。

---

解題方法

一、 參數設定與現金流期程界定

• 折現率 $r = 10\% = 0.1$。
• 第 0 年（系統建置期）：
• 成本：瀑布法開發成本 185 萬元。
• 效益：0 萬元。
• 第 1 年（上線營運第一年）：
• 效益：商業智慧效益 130 萬元。
• 成本：維護與升級費用 20 萬元。
• 第 2 年（上線營運第二年）：
• 效益：商業智慧效益 130 萬元。
• 成本：維護與升級費用 20 萬元、添置資料儲存設備費用 10 萬元，合計成本 30 萬元。

二、 各期各項現值（PV）計算過程（以萬元為單位，四捨五入至小數點後三位）

1. 收益項（Benefits）現值推導：

• 第 1 年收益現值： $PV_{B1} = \frac{130}{(1 + 0.1)^1} = \frac{130}{1.1} \approx 118.182 \text{ 萬元}$
• 第 2 年收益現值： $PV_{B2} = \frac{130}{(1 + 0.1)^2} = \frac{130}{1.21} \approx 107.438 \text{ 萬元}$
• 總收益現值（$PVB$）： $PVB = 118.182 + 107.438 = 225.620 \text{ 萬元}$

2. 成本項（Costs）現值推導：

• 第 0 年開發成本現值： $PV_{C0} = \frac{185}{(1 + 0.1)^0} = 185.000 \text{ 萬元}$
• 第 1 年維護成本現值： $PV_{C1} = \frac{20}{(1 + 0.1)^1} = \frac{20}{1.1} \approx 18.182 \text{ 萬元}$
• 第 2 年營運與設備成本現值：
• 維護升級費用： $\frac{20}{(1 + 0.1)^2} = \frac{20}{1.21} \approx 16.529 \text{ 萬元}$
• 添置儲存設備： $\frac{10}{(1 + 0.1)^2} = \frac{10}{1.21} \approx 8.264 \text{ 萬元}$
• 第 2 年成本小計現值： $PV_{C2} = 16.529 + 8.264 = 24.793 \text{ 萬元}$ （亦即 $\frac{30}{1.21} \approx 24.793 \text{ 萬元}$）
• 總成本現值（$PVC$）： $PVC = 185.000 + 18.182 + 24.793 = 227.975 \text{ 萬元}$

3. 淨現值（NPV）計算： $NPV = PVB - PVC = 225.620 - 227.975 = -2.355 \text{ 萬元}$

三、 成本效益分年現值分析表

核心觀念

本題評量專案時程與成本整合控制之核心技術——實值管理（Earned Value Management, EVM）。涉及之核心定義、計算公式與評估指標如下：

1. 基本衡量參數：

• 規劃值（Planned Value, PV）：在給定時間點內，依專案基準計畫應完成工作的核定預算。
• 實值（Earned Value, EV）：在給定時間點內，實際已完成工作的核定預算（實體完成百分比 $\times$ 該工作之總預算）。
• 實際成本（Actual Cost, AC）：在給定時間點內，執行已完成工作所實際發生的總成本。
• 完工預算（Budget at Completion, BAC）：專案總體工作的總核定成本預算。

2. 績效指標（Performance Index）：

• 時程績效指標（Schedule Performance Index, SPI）： $SPI = \frac{EV}{PV}$
• $SPI > 1$：進度超前。
• $SPI = 1$：進度符合計畫。
• $SPI < 1$：進度落後。
• 成本績效指標（Cost Performance Index, CPI）： $CPI = \frac{EV}{AC}$
• $CPI > 1$：成本節省（低於預算）。
• $CPI = 1$：成本符合預算。
• $CPI < 1$：成本超支（高於預算）。

3. 預測技術（Forecasting - Estimate at Completion, EAC）：

• 當專案初期的成本偏差被視為典型偏差（Typical Variance），即假設未來的成本績效將持續維持目前的 CPI 水準時，完工總成本預估公式為： $EAC = \frac{BAC}{CPI}$ 亦即： $EAC = AC + \frac{BAC - EV}{CPI}$

---

解題方法

(一) 計算第一項工作完成時之 SPI、CPI 與進度落後判定

步驟一：計算專案總預算（BAC）與單項工作預算（PV）

• 專案由 4 項工作前後序列組成，每項工作由甲、乙兩人共同工作 5 天完成。
• 每人每日工資為 1,000 元，兩人每日基本工資共計 $2 \times 1,000 = 2,000$ 元。
• 每項工作之預算： $PV_{\text{每項}} = 2 \text{ 人} \times 5 \text{ 天} \times 1,000 \text{ 元/天} = 10,000 \text{ 元}$
• 專案總預算： $BAC = 4 \times 10,000 \text{ 元} = 40,000 \text{ 元}$

步驟二：確定第一項工作完成時之 PV、EV、AC 數值 題目明確指出評估點為「第一項工作完成時」，並說明「於當天晚上加班完成，加班費計 6,000 元」：

• 規劃值（PV）： 至第一項工作表定完成之第 5 天，預計完成第一項工作的全部工作量。 $PV = 10,000 \text{ 元}$
• 實值（EV）： 在當晚加班完成後，第一項工作已 100% 完工（甲完成負責部分 100%、乙與加班人員共同完成剩餘 100%），故實現全部核定價值。 $EV = 10,000 \text{ 元} \times 100\% = 10,000 \text{ 元}$
• 實際成本（AC）： 包含甲、乙 5 天的正常常態工資，加上當晚加班趕工費用 6,000 元。 $AC = (2 \text{ 人} \times 5 \text{ 天} \times 1,000 \text{ 元}) + 6,000 \text{ 元} = 10,000 + 6,000 = 16,000 \text{ 元}$

步驟三：計算指標並判定進度是否落後

• 時程績效指標（SPI）： $SPI = \frac{EV}{PV} = \frac{10,000}{10,000} = 1.000$
• 成本績效指標（CPI）： $CPI = \frac{EV}{AC} = \frac{10,000}{16,000} = 0.625$

核心觀念

本題評量**軟體測試（Software Testing）階段中的系統測試（System Testing）與非功能性測試（Non-functional Testing）**概念，主要依據軟體工程標準（如 ISO/IEC 25010 軟體品質模型）對於系統品質特性的要求：

1. 效能效率（Performance Efficiency）：系統在特定條件下使用資源的效能表現。
2. 可靠度（Reliability）：系統在指定時間與環境下維持特定效能水準之能力，包含成熟度、容錯性與可回復性。
3. 相容性與可移植性（Compatibility / Portability）：軟體移轉至不同硬體、軟體或其他操作環境時的適應能力。

系統測試為驗證整合後的完整系統是否符合規格需求（SRS），除了驗證業務邏輯的功能性測試外，非功能性測試（效能、壓力、恢復、配置）是確保系統上線後高可用、高穩定及良好使用者體驗的關鍵環節。

---

解題方法

申論題型作答應採**「對稱結構化」**版面，閱卷委員評分重點在於考生能否清楚區分各項測試的本質差異，並切題舉出相應的業務情境。解題切入點如下：

1. 結構切分：針對題目要求的四種測試項目，皆以「意義」、「目的」、「購物網站實例」三段式鋪陳，層次分明。
2. 界線釐清：

• 「效能測試」聚焦於正常/預期負載下的運算能力指標。
• 「壓力測試」聚焦於極限/超額負載下的斷裂點與降級行為。
• 「恢復測試」聚焦於突發故障後的自癒能力與資料一致性。
• 「配置測試」聚焦於異質環境的相容性與適應能力。

3. 情境貼合：實例必須緊扣題幹指定的「購物網站系統」（如一般購物流量、周年慶搶購、金流連線中斷、多終端瀏覽等情境），切忌使用抽像模糊的通用描述。

---

選項分析

本題為高考三級申論題，無選擇題選項。四項測試之對照與分析重點如下：

• 效能測試（Performance Testing）：分析在預期工作量下的反應時間（Response Time）與吞吐量（Throughput），確認系統是否達到服務水準協定（SLA）。
• 壓力測試（Stress Testing）：分析超出規格負荷時的系統耐受力，重點在於驗證系統崩潰時是否具備優雅降級（Graceful Degradation）機制，而非直接無預警宕機。
• 恢復測試（Recovery Testing）：分析非預期硬體、軟體或網路失效後的重啟機制，評估復原時間目標（RTO）與復原點目標（RPO）。
• 配置測試（Configuration Testing）：分析軟硬體排列組合對系統行為的影響，避免因終端環境差異產生相容性漏洞。

---

解題技巧

1. 關鍵字定位法：

• 效能測試看「基準、SLA、回應時間」。
• 壓力測試看「超載、極限、崩潰點、降級」。
• 恢復測試看「故障注入、備援切換、資料完整性」。
• 配置測試看「跨平台、多瀏覽器、環境組合」。

2. 常見陷阱：

• 混淆效能測試與壓力測試：許多考生將兩者混為一談。記住：效能測試測量「平常跑得快不快」，壓力測試測量「何時會被壓垮、垮了會怎樣」。
• 意義與目的混淆：「意義」回答 What（這項測試是什麼、在測什麼），「目的」回答 Why（為何要測、期望達成什麼管理或技術效益）。

3. 高分技巧：作答完畢後，可補充綜合比較表，將負載條件、核心驗證重點濃縮呈現，展現架構化整合能力。

---

【答案】

在系統測試階段，針對壓力測試、效能測試、恢復測試與配置測試四項測試，其意義、目的與購物網站實例如下：

一、效能測試（Performance Testing）

1. 意義： 在系統既定的軟硬體架構與預期的正常工作負載（Workload）條件下，量測系統各項關鍵效能指標（如回應時間 Response Time、每秒交易數 TPS、系統吞吐量 Throughput，以及 CPU/記憶體資源利用率）。
2. 目的：

核心觀念

本題評量敏捷軟體開發（Agile Software Development）的核心哲學與實務本質，重點在於釐清業界與初學者常見的「三大敏捷迷思（Agile Myths）」：

1. 敏捷宣言（Agile Manifesto）之核心價值：

• 敏捷並非「非黑即白」的對立，而是「重於（Over）」的優先級權衡（例如：可用的軟體 重於 詳盡的文件；回應變化 重於 遵循計畫）。

2. 專案管理鐵三角之轉移（Agile Iron Triangle）：

• 傳統計畫導向（Plan-driven，如瀑布模式、CMMI 高成熟度模式）：固定範疇（Fixed Scope），估算時程與成本（Estimated Time & Cost）。
• 敏捷導向（Value/Agile-driven）：固定時程與成本（Fixed Time & Cost，如固定長度的 Sprint/Timebox），彈性調整範疇（Estimated/Flexible Scope）以追求最大商業價值。

3. 敏捷規劃架構（Agile Planning Onion）與滾動式規劃（Rolling Wave Planning）：

• 敏捷反對「巨額前期設計（Big Design Up Front, BDUF）」，但極度仰賴多層次、頻繁且及時的適應性規劃（Adaptive Planning）。

---

解題方法

此類「觀念辨析型是非申論題」是公職專案管理常見的命題手法，作答應採取「破題給定論 $\to$ 引述權威準則（敏捷宣言/專案管理架構） $\to$ 破除迷思原因 $\to$ 正確作法說明」的四段論證結構：

1. 第一步（定性判斷）：第一句話清楚寫出「該敘述不正確（錯誤）」。
2. 第二步（立論基礎）：引用 2001 年《敏捷宣言》的相應條款或 Scrum、XP（極限編程）之規範。
3. 第三步（迷思辨析）：明確指出該論述「誤解了什麼概念」（例如把「減少過度文件」曲解為「完全不寫文件」）。
4. 第四步（專業正解）：說明敏捷在該面向上的實際規範與操作手法，展現閱卷委員期待的專業深度。

---

各子題論述與觀念分析

(一)「敏捷發展法不需要寫文件」之看法

判斷：不正確（錯誤）。

1. 敏捷宣言的原意為「權衡優先級」而非「完全捨棄」：

• 《敏捷軟體開發宣言》第二條明定：「可用的軟體 重於 詳盡的文件（Working software over comprehensive documentation）。」
• 敏捷價值觀強調：右方項目（詳盡文件）仍具價值，只是左方項目（可用的軟體）具備更高的商業與實質價值。敏捷從未主張「不需要寫文件」。

2. 敏捷反對的是「過度與無價值的繁文縟節」：

• 傳統計畫導向往往花費數週至數月產出厚重、未經程式碼驗證的規格書（如 SRS），常在後續開發中迅速過期失效，造成精實軟體開發（Lean）所指的「庫存與重工浪費（Waste）」。

3. 敏捷提倡「剛好足夠且必要的文件」（Just Enough / Bare Minimum Documentation）：

• 敏捷開發仍須撰寫具關鍵價值的文件，包括：使用者故事（User Stories）與驗收標準（Acceptance Criteria）、系統架構設計圖、核心 API 介面規格書（如 OpenAPI/Swagger）、關鍵架構決策紀錄（Architecture Decision Records, ADR）以及法規稽核所要求的合規性文件。
• 此外，敏捷實務倡導「可執行的規格（Executable Specifications）」，如透過行為驅動開發（BDD）的測試案例與自描述（Self-documenting）的乾淨程式碼（Clean Code），將文件動態融入系統本體中。

---

(二)「採用敏捷發展法可縮短系統發展總時程」之看法

判斷：不正確（非必然正確，為常見之認知迷思）。

1. 敏捷的目標是「縮短價值交付週期」，而非「縮短相同功能下的總時程」：

• 敏捷的核心目標是縮短上市時間（Time-to-Market）與首批價值的交付時間（Time-to-Value），透過最小可行產品（Minimum Viable Product, MVP）讓客戶及早取得核心功能並投入營運，而非保證「整套完整系統的總日曆工期」必定縮短。

2. 固定範疇下的工程總工時並未因敏捷而縮減：