112 高普考高考二級 資訊處理 系統分析與設計研究 考古題詳解

核心觀念

極限編程（Extreme Programming, XP）是敏捷開發方法之一，適合需求變動快速、需要頻繁取得使用者回饋的專案。XP 的精神是縮短回饋週期、持續交付可運作的軟體，並透過簡單設計、密切合作與持續改善，降低變更成本。

本題重點是說明 XP 的五項核心價值，以及由這些價值延伸出的主要概念與實務作法。五項核心價值為：

1. 溝通（Communication）：開發者、客戶與團隊成員持續交換資訊，減少需求誤解。
2. 簡單（Simplicity）：只設計並實作目前所需的功能，避免為未來尚未確定的需求過度設計。
3. 回饋（Feedback）：透過測試、頻繁整合及實際使用，儘早發現問題並修正方向。
4. 勇氣（Courage）：敢於修改設計、重構程式、刪除不再需要的功能，並及早揭露問題。
5. 尊重（Respect）：團隊成員彼此重視、共同承擔品質與成果，建立合作而非責怪的工作環境。

解題方法

可先列出五項核心價值，再說明它們如何落實為 XP 的開發概念與實務。答題時應把「價值」與「作法」連結起來：例如，回饋透過短週期交付與測試實現；簡單透過簡單設計實現；溝通則透過客戶參與及結對編程加強。

XP 的主要概念與實務如下：

• 使用者故事與規劃遊戲：由客戶以使用者故事描述需求，團隊共同估算工作量、排定優先順序，並依商業價值與開發能力規劃版本及迭代。
• 小型、頻繁的版本交付：將工作切成短週期，儘早交付可運作的軟體，使客戶能依實際成果提供回饋。
• 測試先行開發（Test-Driven Development, TDD）：先撰寫測試，再實作足以通過測試的程式，之後持續改善程式結構；同時以客戶驗收測試確認需求。

核心觀念

本題考查 UML 類別圖的表示方式，以及如何從需求文字辨識類別、屬性、操作與類別間關係。類別圖描述系統的靜態結構：

• 類別（Class）：以矩形表示，通常分成類別名稱、屬性、操作三格。
• 一般化（Generalization）：子類別繼承父類別，以實線加空心三角箭頭指向父類別。
• 關聯（Association）：表示類別間存在連結，可標示角色名稱及多重性。
• 組合（Composition）：表示整體與部分具有強生命週期依存關係，以實心菱形標示在整體端。部分通常不能脫離整體而獨立存在。
• 多重性（Multiplicity）：標示一個類別的實例可連結到另一端多少個實例，例如 1、0..1、0..*、1..*。

解題方法

先將題目中的名詞轉成候選類別，再將動作轉成類別操作或關聯：

1. 題目明確指出「顧客包含一般顧客和尊榮顧客」，因此建立抽象父類別 Customer，以及兩個子類別 RegularCustomer、PremiumCustomer。
2. 顧客以 username、password 登入，可將兩者列為顧客的屬性，並以 login 表示登入操作。
3. 「瀏覽產品」對應顧客與產品的關聯；「加入購物車」對應顧客使用購物車，購物車再保存多筆購物車明細。
4. 「結帳」會產生訂單；訂單保存訂單明細，並可連結付款資訊。
5. 「使用折扣碼」對應訂單套用折扣碼。題目未規定折扣碼使用限制，因此以每筆訂單可使用零或一個折扣碼建模。
6. 「觀看購買歷史資料」可由顧客與訂單的關聯呈現；購買歷史是顧客過去的訂單集合，不必另外建立重複保存資料的類別。

以下類別圖以 UML 文字形式表示；實線箭頭表示導覽方向，*-- 表示組合，<|-- 表示一般化。

 ┌─────────────────────────────┐
 │ Customer │
 ├─────────────────────────────┤
 │ username: String │
 │ password: String │
 ├─────────────────────────────┤
 │ login: Boolean │
 │ browseProducts: Product[*]│
 │ addToCart(p: Product, qty: Integer) │
 │ checkout: Order │
 │ viewPurchaseHistory: Order[*] │
 └─────────────────────────────┘
 △ △
 │ │
 ┌───────────┴──────┐ ┌───────┴────────────┐
 │ RegularCustomer│ │ PremiumCustomer │
 └─────────────────┘ └────────────────────┘

Customer "1" ─────────────── "0..1" ShoppingCart : 使用
ShoppingCart "1" *────────── "0..*" CartItem : 包含
CartItem "0..*" ──────────── "1" Product : 對應商品

Customer "1" ─────────────── "0..*" Order : 購買／歷史訂單
Order "1" *───────────────── "1..*" OrderItem : 包含
OrderItem "0..*" ─────────── "1" Product : 對應商品
Order "0..*" ─────────────── "0..1" DiscountCode : 套用
Order "1" ────────────────── "0..1" Payment : 付款資料

核心觀念

本題考查政府 IT 專案評估開發策略時，如何用財務分析工具比較方案。三種工具分別著重於「多久回本」、「投資相對於成本的報酬比例」及「考量資金時間價值後的淨效益」。

解題方法

向管理決策階層說明時，可先交代每種工具回答的問題，再說明計算方式與判讀原則：

• 回收分析（Payback Period Analysis）：計算累積效益何時足以抵銷初始投資。若效益每年不同，逐年累加，直到累積淨現金流入抵銷初始成本；若效益固定，可用「初始投資 ÷ 每年淨效益」估算回收期間。回收期間較短，代表資金較快回收。
• 投資回報率（Return on Investment, ROI）：衡量效益相對於成本的比例，常見公式為 $ROI=\frac{\text{總效益}-\text{總成本}}{\text{總成本}}\times100\%$ ROI 越高，代表相對於投入成本所創造的淨效益越高。計算時應明確界定效益、成本與評估期間，並以一致口徑比較方案。
• 淨現值（Net Present Value, NPV）：將各期未來淨現金流量依折現率換算為現值，再扣除初始投資。其公式為 $NPV=\sum_{t=1}^{n}\frac{B_t-C_t}{(1+r)^t}-I_0$ 其中 $B_t$ 為第 $t$ 期效益、$C_t$ 為第 $t$ 期成本、$r$ 為折現率、$n$ 為評估期數，$I_0$ 為初始投資。NPV 大於零，表示方案在納入資金時間價值後，預期效益超過成本；

核心觀念

驗收測試（Acceptance Testing）是由委託機關或其指定代表，依據需求規格、契約及驗收標準，確認外包系統是否符合約定、能否在實際作業環境中支援業務，並據以決定是否辦理驗收。

驗收測試案例不是只列出「測什麼」，還要明確寫出測試條件、操作步驟、預期結果與判定標準，使不同測試人員依相同方式執行時，能得到可重現、可追蹤的結果。

本題重點在於：IT 主管如何從契約與需求建立可執行的驗收測試案例，以及執行時如何保留證據、管理缺失並判定驗收。

解題方法

以「需求與契約為依據、每項需求都有測試證據、測試結果可判定」為主軸。先確認驗收範圍與標準，再建立需求追溯關係，設計涵蓋正常、異常及非功能需求的案例，最後依程序執行、記錄缺失並完成驗收判定。

一、確認驗收依據與範圍

整理並確認下列資料：

• 契約及工作說明書，包括交付項目、履約期限、驗收程序及付款條件。
• 核定的需求規格、系統分析設計文件、介面規格與資料字典。
• 服務水準、效能、安全、備份復原及維運等約定。
• 測試環境、測試資料、參與人員、測試期間與權責分工。
• 驗收通過、限期改善、複驗及不通過的處理方式。

若需求、契約或驗收標準彼此不一致，應在測試前釐清並形成書面紀錄；不可在測試完成後才臨時改變判定標準。

二、建立需求追溯表

將每項需求編號，連結至一個或多個測試案例及驗收標準。例如：

需求編號	需求內容	測試案例編號	通過標準
R-01	承辦人可新增案件	TC-01	欄位驗證正確，案件成功建檔
R-02	主管可核准案件	TC-02	核准後狀態更新，操作紀錄完整
R-03	未授權者不得查閱案件	TC-03	系統拒絕存取，並留下紀錄

需求追溯表可用來確認需求沒有漏測，也可在驗收時說明每項契約要求是如何驗證的。

三、撰寫測試案例

每一個測試案例至少應包含：

• 測試案例編號、名稱及對應需求編號。
• 測試目的與測試範圍。
• 前置條件，例如使用者角色、系統狀態及已準備的資料。
• 測試資料，包括輸入值、資料來源及必要的邊界值。
• 逐步操作程序。
• 每個步驟的預期結果。
• 通過與失敗判定標準。
• 實際結果、執行日期、執行人員及證據。
• 缺失編號、嚴重程度、處理狀態及複驗結果。

測試案例應以可觀察、可判定的結果撰寫。「系統正常」或「畫面正確」過於籠統，宜改成「輸入必填欄位後按下送出，系統新增一筆案件，案件編號顯示於畫面，資料庫紀錄與畫面內容一致」。

四、涵蓋主要測試類型

依系統功能與契約要求安排測試案例，至少考量：

1. 功能測試：逐項驗證新增、查詢、修改、刪除、簽核、報表等功能。
2. 正常與例外情境測試：測試有效輸入、錯誤輸入、缺漏欄位、重複資料、無效狀態及權限不足等情形。
3. 流程與介面測試：驗證跨模組流程、外部系統介接、資料交換、錯誤回應及重送處理。
4. 資料測試：檢查資料正確性、完整性、筆數、欄位對應、轉檔結果及資料保留情形。
5. 權限與安全測試：依角色測試可執行及不可執行的操作，並檢查登入、登出、操作紀錄及敏感資料保護。
6. 非功能測試：依契約標準驗證效能、容量、可用性、備份復原、相容性及易用性等要求。
7. 安裝與維運測試：驗證部署、設定、監控、備份、還原、故障處理、操作手冊及教育訓練等交付內容。

非功能測試須引用明確的門檻，例如回應時間、併發使用者數、可用率或復原時間；若契約沒有相關標準，應先確認可採用的驗收判準並留下書面紀錄。

測試案例步驟範例

案例編號： TC-01 案例名稱： 承辦人新增案件 對應需求： R-01 測試目的： 確認承辦人可依規定輸入案件資料並完成建檔。