110 身心障礙特考三等 資訊處理 資訊系統與分析 考古題詳解

核心觀念

本題考查軟體專案在開發前的可行性評估。評估目的在於判斷專案是否值得投入、是否能實際完成，以及能否在預定條件下順利運作。題目所列的經濟、技術、法規與時程，是常見的四項評估面向。

本題不涉及特定法條；若專案受個資、著作權、資通安全或採購規範影響，應依命題當年適用的相關法規另行檢核。

解題方法

作答時依四個面向逐一說明「評估什麼」及「判斷重點為何」，避免只列面向名稱。可將核心問題記成：

• 經濟：投入與效益是否相稱？
• 技術：系統能否建置、整合並維護？
• 法規：設計與運作是否符合規範？
• 時程：能否在期限內完成並上線？

各面向考量重點

一、經濟可行性

評估專案的成本、效益及其合理性，判斷投資是否值得。成本除軟硬體與開發費用外，也應納入導入、教育訓練、維護、升級及後續營運等成本；效益則包括可量化的收益或節省，例如減少人工作業時間、降低錯誤率與作業成本，也包括較難量化的服務品質提升、資訊透明度及決策改善。

應比較專案全生命週期的成本與預期效益，並考量效益發生時間、資金來源及資源配置，確認專案在預算限制下具有合理的經濟價值。

二、技術可行性

評估組織是否具備完成專案所需的技術與能力。重點包括：

• 技術與工具是否成熟，能否支援預定功能及效能需求。
• 現有設備、資料庫、網路與其他系統能否整合。
• 是否具備適當的人力、技術經驗與開發能力。
• 系統的安全性、可靠性、擴充性與維護性是否可達成。
• 技術風險是否可控，例如關鍵技術尚未成熟或高度依賴特定供應商。

技術可行性不只是在確認「做不做得出來」，也要確認系統完成後能否穩定使用、維護及持續擴充。

三、法規可行性

核心觀念

服務水準協議（Service Level Agreement, SLA）是機關與系統服務廠商約定服務品質、衡量方式、責任分工及未達標處理方式的文件。題目著重兩類指標：

• 系統效能（Performance／Responsiveness）：系統在特定工作量及使用條件下，處理請求的速度與能力。常用指標包括回應時間、交易處理量、併發使用者數及錯誤率。題目括號中的 responsibility 並非常見的效能指標名稱；此處依題意說明系統效能，常見英文用語為 performance 或 responsiveness。
• 系統可用性（Availability）：系統在約定服務時間內，能正常提供服務的比例。須事先說明服務時間、正常服務的判定標準、計算期間，以及計畫性維護與非計畫性停機如何計算。

SLA不能只寫「效能良好」或「維持穩定」，而須將服務品質轉成可量測、可查證的指標，並約定資料來源、檢核頻率及未達標的處理方式。

解題方法

本題是委外規格的說明題，可採「定義指標 → 設定門檻 → 約定檢核 → 規定未達標處理」的順序作答。效能須交代測試條件及回應時間；可用性則須交代計算公式、期間及停機認定，才能讓機關實際驗收與持續管理。

一、系統效能規定

效能指標應以使用者實際操作的關鍵服務為對象，例如登入、查詢、送出申請及產製報表。規格應訂定：

1. 測試情境：測試功能、資料量、網路環境及併發使用者數。
2. 衡量指標：例如平均回應時間、第 95 百分位回應時間、每秒交易數及錯誤率。第 95 百分位回應時間表示 95% 的請求都在該時間內完成，可避免少數極快請求掩蓋多數使用者的等待情形。
3. 合格門檻：例如在 500 名併發使用者下，一般查詢的第 95 百分位回應時間不超過 3 秒，且錯誤率低於 1%。
4. 檢核方式：上線前以負載測試工具模擬約定情境；上線後以應用程式監控、伺服器紀錄及定期報表追蹤。

核心觀念

本題考查資訊系統災變回復規劃中的兩項服務水準指標，以及如何依業務需求配置回復資源。RTO 與 RPO 都是災後回復目標，不是描述系統實際回復結果的保證值。

• RTO（Recovery Time Objective，復原時間目標）：災變發生後，系統或業務服務必須在多長時間內恢復至可接受運作狀態。它描述可容忍的服務中斷時間上限。
• RPO（Recovery Point Objective，復原點目標）：災變發生後，資料回復至某一時間點時，可容忍的最大資料遺失範圍。它描述可容忍的資料回復落差，通常以時間表示。

例如，若 RTO 為 4 小時，表示業務要求在災變後 4 小時內恢復服務；若 RPO 為 1 小時，表示回復資料最多只能落後災變發生時間 1 小時，因而可能須重建或補登這段期間的資料。

解題方法

作答可依「先定義指標，再說明規劃依據，最後連結資源」的順序展開。規劃時應由業務影響與可容忍損失出發，而不是先決定備援設備，再反推服務目標。

一、規劃 RTO／RPO 的考量重點

1. 業務衝擊與系統重要性 盤點各系統支援的業務流程、服務對象、交易量，以及中斷或資料遺失對機關運作、民眾服務、財務與信譽造成的影響。核心或高關鍵性系統通常需要較短的 RTO 與 RPO。

2. 業務可容忍中斷時間與資料損失 透過業務衝擊分析（BIA）確認各項業務最多能停擺多久，以及最多能接受多少資料遺失。RTO 著重服務何時恢復；RPO 著重資料需回復到多接近災變發生前的狀態，兩者不可混為一談。

3. 系統相依性與回復順序 確認應用系統、資料庫、網路、身分驗證、電力、雲端或外部服務等相依關係，並安排回復優先順序。若某系統依賴的基礎服務尚未恢復，即使系統本身已啟動，也未必能提供可用服務。

4. 災變情境與回復程序 考量設備故障、誤刪或資料損毀、勒索軟體、機房事故及區域性災害等情境。規劃須包含備份與複寫、異地備援、切換流程、資料驗證、人工替代作業及復原演練，並確認災後能在目標時間內完成。

5. 人力、技術與供應商條件 評估回復所需的專業人員、操作程序、備援環境、網路頻寬、硬體容量、軟體授權，以及供應商支援時間與服務水準。資源或人員到位時間也會影響實際可達成的 RTO。

核心觀念

本題考查系統開發生命週期中的測試類型與目的。答題時應依「測試範圍由小到大」及「測試目的」說明：先確認單一程式單元，再確認單元間的介面與合作，接著驗證完整系統是否符合需求；壓力測試與滲透測試則分別著重負載下的效能與安全弱點。

解題方法

逐項交代每種測試的測試對象、主要目的與典型問題，並辨明它們所處的測試層次。前四類中，單元、整合與系統測試是由局部到整體的功能驗證；壓力測試屬效能與穩定性測試；滲透測試則是以安全攻擊角度檢驗防護能力。

各類測試說明

一、單元測試（Unit Testing）

以最小且可獨立測試的程式單位為對象，例如函式、方法、類別或模組。通常由開發人員執行，確認該單位在指定輸入下能否產生預期結果，並處理邊界條件及錯誤輸入。

若受測單元依賴尚未完成的其他模組，可用測試替身（如 stub 或 mock）模擬依賴項目。此階段著重程式單位本身的邏輯正確性，不負責驗證整個系統流程。

二、整合性測試（Integration Testing）

將已測試的單元或子系統逐步組合，檢驗它們能否正確互動。重點包括模組介面、資料傳遞格式、呼叫順序、錯誤處理，以及與資料庫、外部服務或其他系統的介接。

單元各自測試通過，不代表整合後一定正常；例如兩個模組對欄位格式的認知不同，或呼叫介面不一致，都可能在整合時才暴露。整合方式可採由上而下、由下而上或逐步整合。

三、系統測試（System Testing）

將完整整合後的系統視為一個整體，依據需求規格驗證是否符合預期。測試範圍可涵蓋功能，也可包括效能、相容性、可靠性、可用性等非功能需求。