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

核心觀念

可行性分析（Feasibility Analysis）是在系統開發或重大作業變革前，評估「提出的方案是否做得到、是否值得做，以及是否能在限制內完成」。它不是單純判斷技術能否運作，而是從技術、成本效益、組織作業、時程及法規等面向，判斷方案的整體實用性。

本題應先說明可行性研究的類型與一般步驟，再把這些面向逐一套用到「公立醫院實施遠距醫療」的情境。分析時要同時考慮醫療服務品質、病人安全、資訊安全與法規遵循。

可行性研究的類型

常見分類可用 TELOS 記憶：

1. 技術可行性（Technical Feasibility） 評估現有或可取得的技術、設備、網路及人力，能否支援系統需求，例如視訊診療、病歷整合、身分驗證、資料傳輸及備援機制。

2. 經濟可行性（Economic Feasibility） 評估建置與營運成本，以及預期效益是否合理。成本效益分析可比較系統建置、設備、維護、資安及訓練等成本，與節省的交通及人力成本、增加的服務量、提升的照護可近性等效益。效益包含難以直接換算金額的非財務效益。

3. 作業或營運可行性（Operational Feasibility） 評估系統是否符合醫院與病人的實際需求，是否能融入既有流程，以及醫師、護理人員、行政人員和病人是否願意採用。亦須檢視人力配置、教育訓練、客服及故障處理方式。

4. 時程可行性（Schedule Feasibility） 評估是否能在預定期限內完成採購、建置、測試、訓練及正式上線，並考量法規審查、系統整合、院內採購程序與分階段導入的時間。

5. 法律與法規可行性（Legal Feasibility） 評估方案是否符合醫療、個人資料、病歷保存、健保給付及資訊安全等規範。醫療服務不能只以技術上可行為由省略法定資格、程序與紀錄要求。

可行性研究的執行步驟

1. 界定問題、目標與範圍 說明目前的服務問題、預期改善目標及研究範圍。例如，偏遠地區病人往返不便，醫院評估是否以遠距方式提供特定門診或追蹤服務。須界定服務對象、科別、地點與服務項目。

2. 蒐集現況與需求資料 了解現行看診流程、病人需求、醫療人力、資訊系統、設備、網路條件、成本及相關法規。確認各類利害關係人需求，包含醫師、護理人員、行政單位、資訊室及病人。

3. 提出可行方案與限制條件 比較自建、採購或委外等方案，並訂出服務範圍、預算、人力、資安及預定時程等限制。方案可包含先導計畫與全面導入兩種規模。

4. 分面向評估各方案 依技術、經濟、營運、時程及法律面向，分析各方案的優缺點、成本、效益、風險與必要配套。必要時以量化資料支持比較，例如設備成本、預估服務量、等待時間及交通成本。

5. 比較方案並提出建議 綜合各面向結果，選出最符合目標且可接受的方案，說明選擇理由、主要風險及控制措施。若方案尚未達成特定條件，應列出補足條件後再推動。

6. 撰寫可行性研究報告，供決策者核定 報告應包括問題與目標、需求及限制、方案比較、成本效益、法規檢核、風險與建議。核定後再進入詳細規劃或系統開發階段。

公立醫院遠距醫療的可行性分析

一、技術可行性

醫院可建置具視訊、聲音及必要影像傳輸功能的遠距醫療平台，並整合掛號、身分確認、病歷查詢、診療紀錄及後續追蹤流程。醫療端須配置適當的攝影、收音、顯示及網路設備；病人端則須具備可使用的裝置與網路，並提供必要的操作協助。

系統設計須支援身分驗證、權限控管、傳輸加密、操作紀錄、資料備份及故障備援。與既有電子病歷、掛號及藥事流程整合，可減少重複輸入與資訊落差。醫院也須安排資訊維運人員，建立平台故障、網路中斷及設備異常時的處理流程。

核心觀念

本題考查三種敏捷開發中的測試方法，需說明其測試層級、參與角色、測試描述方式，以及從資訊安全角度如何將安全需求納入開發。三者的共同原則是先定義可驗證的預期結果，再以測試回饋引導實作；差異主要在於測試所描述的對象與抽象層次。

資訊安全需求可涵蓋身分驗證、存取控制、輸入驗證、資料保密性、稽核紀錄與錯誤處理等。例如，測試可驗證未授權使用者無法讀取敏感資料、輸入惡意內容會被妥善處理，以及重要操作會留下稽核紀錄。

解題方法

依照「測試範圍由小到大、描述方式由技術到業務」整理：

1. TDD：以單元測試描述程式元件的預期行為，開發者先寫失敗測試，再實作至通過。
2. ATDD：以使用者故事與驗收條件描述功能是否符合需求，由業務、測試與開發等角色共同確認。
3. BDD：以共同理解的行為情境描述系統在特定條件下的預期反應，常用 Given–When–Then 格式，銜接業務需求與自動化測試。

答題時應指出：三者都能支援安全需求驗證，但都不能單獨取代威脅建模、弱點掃描、滲透測試及安全程式碼審查。

三種敏捷測試方法比較

核心觀念

本題考查兩種策略分析工具的用途與焦點：

• NSDB 金三角分析：用來檢視創新構想或產品服務能否形成有價值的提案。其四個要素為需求（Needs）、解決方案（Solution）、差異化（Differentiation）及效益（Benefits）。
• SWOT 分析：用來盤點組織內部的優勢（Strengths）、劣勢（Weaknesses），以及外部環境的機會（Opportunities）、威脅（Threats），據以研擬策略。

解題方法

題目要求「分別說明」並「比較異同」，作答可先分別界定兩種工具，再從分析對象、構面、用途與產出加以比較。NSDB 的核心順序是由顧客需求出發，提出解決方案，說明相較於替代方案的差異，最後交代顧客或組織能獲得的效益；SWOT 則先辨識內外部條件，再據以選擇行動方向。

NSDB 與 SWOT 分析比較

核心觀念

本題在比較三種測試所回答的問題：

• 白箱測試：程式內部的控制流程與邏輯是否正確？
• 黑箱測試：系統對各種輸入是否產生符合需求的輸出與行為？
• 壓力測試：系統在超出正常負載的情況下，是否能承受、穩定退化或妥善復原？

三者著眼點不同，應搭配使用。白箱、黑箱主要描述測試設計依據與觀察角度；壓力測試則屬於非功能測試中的效能測試，三者並非完全互斥的分類。

解題方法

依「測試依據、測試者、測試重點、案例」逐一比較，再以由小到大、由內而外的層次安排先後：先檢驗個別程式邏輯，再驗證需求功能，最後在整合環境中施加高負載。若採敏捷開發或持續整合，測試可能反覆執行；本題所問的先後次序，採一般開發流程說明。

三種測試比較