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

核心觀念

本題考查系統開發策略的選擇，以及低程式碼／無程式碼（Low-Code/No-Code, LCNC）平台如何改變企業自建系統的成本、速度、控制權與風險。自建與外包是「由誰負責開發」的策略；LCNC 則是「以何種工具與方式開發」，企業可用它支援自建，也可能用它與外包或既有系統搭配。

解題方法

（一）從開發責任、成本與時程、控制與彈性、能力與風險等面向比較自建與外包。

（二）以企業自建的「效益」與「限制」兩面作答，並把 LCNC 的特性連結到企業內部的開發能力、治理需求及系統整合。這樣能避免只列平台功能，而未回答其對自建策略的實際影響。

（一）自建開發與外包開發的特性（10 分）

自建開發（In-house Development）

企業自行以內部人員、工具與資源規劃、設計、建置、測試及維護系統。

• 掌握度高：企業可直接控制需求優先順序、架構、開發進度、資料與程式碼。
• 符合企業需求：內部團隊熟悉組織流程及領域知識，較能將系統設計貼合特殊作業需求。
• 溝通與調整直接：使用者與開發人員較容易持續討論、快速調整需求。
• 累積內部能力：開發過程可培養技術、系統維護及問題處理能力，知識也較容易留在企業內。
• 初期投入與人才需求較高：企業須自行負擔人力、工具、訓練及管理成本；缺乏關鍵技術人才時，專案進度與品質容易受影響。
• 維護責任由企業承擔：系統上線後的修正、資安更新、備援與持續營運，均須有內部能力及資源支撐。

外包開發（Outsourcing）

企業將系統開發的部分或全部工作委託外部廠商執行，並依契約約定範圍、時程、交付成果及服務水準。

• 取得外部專業與人力：可利用廠商的技術經驗、開發工具及專案團隊，補足企業自身能力不足。
• 可減少自行培訓與建置負擔：企業不必為單一專案長期維持完整開發團隊，但仍須投入需求管理、廠商管理及驗收人力。
• 責任與交付可透過契約約定：例如功能範圍、時程、品質、維護及服務水準；契約設計與履約管理會影響實際成果。
• 客製化與變更受委託範圍限制：需求變更可能涉及追加費用、排程調整或契約協商，反應速度未必能配合業務變化。
• 知識與依賴風險較高：文件、程式碼或領域知識若未妥善移交，企業可能依賴特定廠商，後續維護與轉換成本提高。
• 需管理資安、資料及品質風險：委外涉及資料存取、機密保護、權限管理、品質驗收及服務不中斷等議題，不能只以降低成本作為決策依據。

（二）LCNC 對企業採用自建開發的正反面影響（15 分）

LCNC 平台以視覺化介面、拖放元件、表單、流程與預建模組降低撰寫程式碼的需求。低程式碼仍可搭配程式撰寫來擴充功能；無程式碼則通常更仰賴平台內建的功能與規則。兩者皆不代表完全不需要需求分析、測試、資安與維護。

正面影響

1. 縮短開發與交付時間 平台提供預建元件及流程設計工具，可減少重複撰寫程式碼的工作，讓部門應用或原型較快完成，也有助於因應小幅度、頻繁的業務變更。

核心觀念

本題考查需求分析中「功能需求」與「非功能需求」的區分與具體化。

• 功能需求（Functional Requirements）：描述系統必須提供的服務與行為，也就是系統「要做什麼」。可由使用者目標、操作順序、系統回應及例外情境整理而得。
• 非功能需求（Non-Functional Requirements）：描述系統服務應達到的品質或限制，也就是系統「要做得多好」。本題要求從效能、可靠性、可用性、安全性、易用性五個面向，將「快速」「不出錯」「容易操作」等抽象期待寫成可驗收的條件。

題目未提供流量、服務時段、資安政策等數值，因此以下非功能需求採合理的購票網站假設示範；實際專案應再依服務目標、使用者及營運需求確認門檻。

解題方法

先依使用者敘述的操作順序整理使用案例：登入、查詢演唱會與票況、選場次、看座位圖、選座、填資料、付款、寄送電子票。再把系統對「座位已售出」與「刷卡失敗」的回應列為例外流程。

撰寫功能需求時，以「系統應……」描述可觀察的功能，並涵蓋正常流程與失敗流程。撰寫非功能需求時，則將品質要求量化或設定明確驗收條件，避免只寫「快速、安全、方便」等無法測試的形容詞。

（一）功能需求

1. 使用者登入：系統應提供登入功能，讓使用者在購票前輸入帳號及驗證資訊；登入成功後，才能進入購票流程。
2. 查詢演唱會與票況：系統應允許使用者查詢指定演唱會，並顯示其場次、票價及各場次目前的可售狀態。
3. 選擇演唱會場次：使用者應能從查詢結果中選擇欲購買的場次。
4. 查看座位圖：系統應依所選場次顯示座位圖，並呈現座位位置、票價及座位狀態。
5. 選擇與比較座位：系統應允許使用者挑選一或兩個符合預算的座位，查看其位置及價格，並決定購買的座位。系統應在使用者確認前顯示所選座位與應付金額。
6. 填寫購票人及付款資料：使用者決定座位後，系統應提供資料填寫介面，供使用者輸入姓名及付款資訊，並在送出前檢核必要欄位。
7. 確認座位仍可購買：使用者按下付款後，系統應再次確認所選座位仍未售出；若座位已被其他人購買，系統應提示座位已不可購買，並引導使用者重新選擇座位。
8. 信用卡付款：系統應將付款資料送交付款服務進行交易，並接收及判讀付款成功或失敗的結果。
9. 處理付款失敗：付款失敗時，系統應通知使用者購票未完成，並提供重新嘗試付款或返回重新選位的流程；失敗交易不得被記錄為已完成購票。
10. 完成購票及寄送電子票：付款成功且座位確認完成後，系統應建立購票紀錄、更新座位狀態，並將電子票寄送至使用者的電子郵件信箱。
11. 顯示交易結果：系統應向使用者顯示購票成功或失敗的結果；成功時應提供訂單資訊，失敗時應說明後續處理方式。

流程上的必要控制

座位確認、付款及訂單建立必須避免產生重複售票或「已付款但未取得票」等不一致狀況。系統應清楚處理座位保留期限、付款逾時及付款結果不明等情形，並依交易結果更新訂單與座位狀態。電子票寄送失敗時，購票紀錄仍應保留，並提供再次寄送或由使用者查閱電子票的方式。

（二）非功能需求

以下門檻是可驗收的示例，實際數值應在需求確認階段依預估流量與服務目標定案。

1. 效能（Performance）

• 一般負載下，演唱會查詢、票況查詢、場次選擇及座位圖載入等主要操作，95% 的請求應在 2 秒內完成。
• 送出付款後，系統應在 5 秒內顯示處理中或交易結果；

核心觀念

本題考查由 Use Case Description（使用案例描述） 的主要流程，辨識領域中的類別、屬性、方法與關聯，並轉換成 UML 類別圖。題目指定繪製 5 個重要類別，重點是讓類別能支援「搜尋可借車與空位、啟動借車、身分及付款驗證、開鎖與還車結算」等流程。

類別圖的基本概念如下：

• 類別：描述具有共同資料與行為的物件，例如單車、站點、租借紀錄。
• 屬性：記錄類別的狀態或資料，例如單車車種、站點可借數量。
• 方法：表示類別可執行的行為，例如驗證付款、開鎖、結算費用。
• 關聯：表示類別間的結構關係，可用多重度說明數量，例如一個站點有多輛單車。

解題方法

先從流程中的名詞找出候選類別，再依責任分配資料與行為。流程裡重要的領域名詞包括「借車人、單車、站點、付款方式、租借紀錄」；題目限為 5 個類別，因此以能涵蓋主要流程的五類為主：

1. 借車人：發起借還車，具會員身分與付款資料。
2. 單車：有車種、狀態與車鎖，並參與借車及還車。
3. 站點：提供可借車輛與可還空位資訊。
4. 租借紀錄：保存借車、還車時間與站點，以及租借狀態與費用。
5. 借還車系統：協調搜尋、驗證、開鎖、鎖車、結算及顯示提示等流程。

付款方式與車鎖不另列為類別，分別作為借車人的屬性及單車的屬性／行為，以符合題目要求的五類規模。以下以 UML 常見的 + 表示公開方法，- 表示私有屬性；屬性與方法以英文命名時，均附中文說明。

UML 類別圖

核心觀念

本題考查物件導向設計的高內聚（High cohesion）與低耦合（Low coupling）。

• 高內聚：一個類別的屬性與方法應共同服務於該類別明確、集中的職責。方法若處理的是其他類別或其他業務領域的工作，會使類別職責分散、內聚度降低。
• 低耦合：類別之間的依賴應盡量少且明確。某類別若直接處理其他類別的資料，或負責外部付款、物流等服務，便會增加相依關係；被依賴的類別一旦改動，相關類別也容易受影響。

解題方法

逐一檢視圖 1、圖 2 中各類別的屬性與方法，判斷每個方法是否服務於該類別的核心職責，再觀察方法參數與工作內容是否使類別直接依賴其他類別或外部服務。

圖 1 中，Customer、Product、Invoice 各自承擔了多項跨領域工作；圖 2 則把庫存工作留在 Product、發票工作留在 Invoice，並由 Customer 負責顧客購物及下單相關操作。因此，設計較差的是圖 1。

圖 1 違反高內聚、低耦合之處

一、Customer 類別職責混雜

Customer 的屬性包括客戶識別碼、姓名、電子郵件、收件地址及付款方式，這些資料符合客戶本身的描述。但圖 1 又把下列工作放進 Customer：

• searchProduct(keyword)、viewProduct(productId)：處理產品搜尋與查詢，屬於產品目錄或產品查詢職責。
• addToCart(productId, quantity)：處理購物車內容，較適合由購物車或購物流程物件負責。
• CalculateTax(Invoice)：計算發票稅額，屬於發票金額計算工作；方法還直接接收 Invoice，增加 Customer 對 Invoice 的依賴。
• UpdateProductStock(product, qty)：更新產品庫存，屬於 Product 的庫存管理職責；Customer 直接接收 Product 參數，形成跨類別依賴。
• CapturePayment(token, amt)：處理付款請款，屬於付款服務或付款流程，不是客戶資料管理職責。
• Checkout(ProductID, qty)：將購物流程與產品數量處理交給 Customer，容易使 Customer 同時負責客戶資料、購物、庫存、稅額及付款等不同工作。

因此，Customer 類別的職責不集中，違反高內聚；它也直接依賴 Invoice、Product 與付款流程，違反低耦合。

二、Product 類別混入非產品職責

Product 的產品編號、名稱、描述、單價、庫存及分類，與產品本身相符；reserveStock(quantity)、commitStock(quantity) 也屬於庫存管理。但圖 1 還包含：