112 地方特考三等 資訊處理類科 系統專案管理 考古題詳解
第 一 題25 分
你是一家醫院的資訊長，該院正在規劃重建使用多年的醫療管理系統。最近外界有發生一些資安事件，使得該院的院長非常擔心醫療管理系統裡面那些屬於特種個資的病歷資料與病患的個人資料發生外洩。
請大致向院長說明並建議：這次開發醫療管理系統的專案中，在規劃（Planning Phase）、設計（Design Phase）以及開發（Development Phase）的各個階段，可以採取什麼樣的措施，以防止這個系統未來發生危害資料安全的事件？
登入後即可作答並保存紀錄。
核心觀念
本題考查的是安全開發生命週期（Secure Software Development Life Cycle, SSDLC）：把資安要求納入系統規劃、設計與開發，而不是等系統上線後才補救。醫療管理系統處理病歷與病患個人資料，須特別重視機密性、完整性與可用性，並降低未授權存取、資料外洩、資料遭竄改及服務中斷等風險。
以命題當年（民國 112 年）法規為準，病歷及醫療資料屬《個人資料保護法》第 6 條所列的特種個人資料，原則上不得蒐集、處理或利用，須符合該條規定的例外及相關要件。醫院亦須依《個人資料保護法》第 27 條採取適當安全措施，防止個人資料遭竊取、竄改、毀損、滅失或洩漏。資安措施應依資料敏感程度、威脅與風險規劃，並落實於系統各階段。
解題方法
依題目指定的三個階段作答，並以「先辨識風險與需求、再把安全落入架構、最後以安全工程驗證」為主軸。每個階段都要說明可執行的措施，且措施應對應病歷資料的機密性、完整性與可用性。
各階段建議措施
一、規劃階段（Planning Phase）
-
盤點資料與法規要求 盤點系統會蒐集、處理及利用的資料種類、來源、流向、保存期間及使用目的，標示病歷等敏感資料，確認蒐集與利用的法定依據、告知義務及存取限制。遵守個資法及醫療相關法規，並納入院內資安政策與稽核要求。
-
進行風險評估與威脅分析 評估資料外洩、帳號遭盜用、勒索軟體、內部人員不當查閱、系統遭竄改或服務中斷等威脅，分析其發生可能性與衝擊，排定處理優先順序。據此訂定風險處理方式與可接受風險標準。
-
訂定資安需求與責任 將身分驗證、最小權限、資料加密、操作紀錄、備份復原、弱點管理、事件通報等需求納入專案規格、採購條件及驗收標準。明確指派醫院、開發團隊及委外廠商的資安責任，要求廠商遵循安全開發與保密要求。
-
規劃治理與事件應變 指定系統及資料負責人、權限核准流程、定期稽核方式與資安事件通報窗口；規劃發生外洩或服務中斷時的應變、調查、復原及對外通報流程。
二、設計階段（Design Phase）
-
採用安全架構與縱深防禦 依信任邊界區分網路、應用程式及資料庫區域，限制各區域間的通訊，避免單一防護失效即造成全面暴露。將管理介面與一般使用介面分離，並設計必要的網路存取控制。
-
落實身分識別與存取控制 設計個別帳號、強式驗證及適當的多因子驗證；依角色與職務授予最小必要權限，限制醫事人員只能存取業務所需的病患資料。規劃權限申請、核准、異動及離職停權流程，並對緊急存取設定特別授權與事後稽核機制。
第 二 題25 分
在系統開發的過程中，測試腳本與測試資料的擬訂，應該由系統分析師還是程式設計師主要負責？如果他們合作，建議他們彼此間可以如何協作？
登入後即可作答並保存紀錄。
核心觀念
測試腳本與測試資料的設計，涉及兩種互補的專業：
- 系統分析師掌握需求、業務規則與系統應有的行為，主要從「系統是否符合需求」的角度，定義測試情境、預期結果與驗收條件。
- 程式設計師掌握程式結構、介面、資料格式及技術限制，主要從「如何有效執行測試」的角度，設計或補充測試資料、測試工具與技術性測試案例。
因此，測試不是單一職務獨力完成的工作。若問誰應「主要負責」，應以系統分析師主導測試情境與預期結果，程式設計師配合實作並補足技術測試為原則。實際分工仍須依組織角色安排及專案規範調整。
解題方法
依測試目的區分工作內容：
-
先確認測試依據 系統分析師將需求規格、使用案例、業務流程及驗收標準轉為可驗證的測試條件，例如輸入、操作步驟、預期輸出及通過／失敗判準。
-
再設計測試資料 測試資料要能涵蓋正常情況、邊界值、錯誤輸入及例外流程。系統分析師依業務語意確認資料是否代表真實情境；程式設計師確認資料格式、資料庫限制、介面需求及測試環境是否支援。
-
補充技術層面的測試 程式設計師可依程式設計與系統架構，補充單元測試、模組介面、錯誤處理、例外狀況及效能等技術測試。這些測試不能取代依需求所建立的功能與驗收測試。
第 三 題25 分
有位客戶想要開設一家咖啡簡餐店。該店除了各種高級咖啡與飲料之外，還提供一些點心與蛋糕。
請為這家咖啡簡餐店設計一個訂單管理系統的資料庫架構。請說明其大致包括哪些檔案與欄位，以及它們的主鍵和彼此之間的外鍵關係。
登入後即可作答並保存紀錄。
核心觀念
本題考查關聯式資料庫的需求分析與資料表設計。設計時要辨識店內的主要資料對象，將各對象分成資料表，並用主鍵識別每筆資料、用外鍵表達資料表間的關聯。訂單與品項是多對多關係：一張訂單可有多種品項，同一種品項也可出現在多張訂單，因此需以「訂單明細」作為中介資料表，並在其中記錄數量與成交單價。
解題方法
依「客戶下單、訂單列出品項、店家提供商品」的流程，設計客戶、商品、訂單及訂單明細四類資料表。商品涵蓋咖啡、飲料、點心與蛋糕，以商品類別欄位區分；訂單明細記錄每筆訂單包含的商品與數量。
以下欄位為參考設計，主鍵以 PK 標示，外鍵以 FK 標示。
| 資料表 | 欄位與鍵值 |
|---|---|
| 客戶 Customer | customer_id（PK）、customer_name、phone、email、created_at |
| 商品 Product | product_id（PK）、product_name、category、unit_price、is_available |
| 訂單 Orders | order_id（PK）、customer_id（FK）、order_time、order_status、note |
第 四 題25 分
請問根據物件導向設計（Object-oriented design, OOD）的概念，在一所學校裡面的在學學生，如果要把他們在學校教學系統裡設計成一個物件類型（Class），這個學生的物件類型大致應該具有什麼樣的屬性（Attributes）與方法（Methods）？請說明你想要這樣設計的理由。
登入後即可作答並保存紀錄。
核心觀念
本題考查物件導向設計（OOD）中，如何依照領域需求定義類別的屬性與方法。類別是同一類物件的設計藍圖；屬性描述物件的狀態，方法則描述物件可執行的行為。
設計時應從「在學學生在教學系統中需要被辨識、管理及提供哪些服務」出發，而非把學生可能具有的所有個人資料與行為都納入。屬性須能支援系統需求，方法則應與學生身分及系統職責相符。
解題方法
可先界定系統範圍，再分別整理資料與行為：
- 界定學生在系統中的角色：學生是修課、查詢學習資訊與參與教學活動的使用者。
- 整理必要狀態：系統需要辨識學生、確認其在學身分，並管理其系所、班級及修課等資訊。
- 整理學生相關行為：列出學生可透過系統進行的操作，例如選課、查詢課表與成績、提交作業。
- 檢查設計是否合宜：僅納入教學系統需要的資訊與操作；敏感或無關資料不應無故存入學生類別。
參考設計
屬性（Attributes）
| 屬性 | 說明 |
|---|---|
studentId（學號） | 系統內辨識學生的唯一識別值。 |
name（姓名） | 顯示學生身分所需的基本資料。 |
department（系所） | 表示學生所屬的學術單位。 |
class（班級） | 表示學生目前所屬班級。 |
enrollmentStatus（學籍狀態） | 記錄在學、休學、退學或畢業等狀態，供系統判斷可用服務。 |
enrolledCourses（修課清單） | 關聯學生目前修習的課程；實際設計通常以學生與課程之間的關聯表示。 |
contactEmail（聯絡信箱） | 用於系統通知或教學聯絡。 |
依需求也可增加年級、入學年度等欄位。密碼、身分證字號等敏感資訊應遵循權限控管與資料最小化原則，不能只因為是學生資料就一律納入此類別。
方法（Methods）
| 方法 | 說明 |
|---|---|
enrollCourse(course)（選課） | 申請修習課程，並由系統檢查選課資格、名額或先修條件。 |