112 警察特考三等 警察資訊管理人員 警政資訊管理與應用 考古題詳解

核心觀念

本題考查系統開發方法與雲端、生成式 AI 服務整合時的適用性評估。機關透過 Azure、ChatGPT 等服務的 API 建置專屬應用，通常不是從底層自行開發大型系統，而是整合外部平台、機關資料、業務流程與使用者介面。系統能否成功，除了程式是否完成，也取決於服務需求是否正確、外部 API 是否穩定、資料是否妥善保護，以及後續能否持續維運。

系統開發生命週期（System Development Life Cycle, SDLC）是涵蓋需求、分析、設計、建置、測試、部署及維護等階段的管理架構；瀑布法則是依序完成各階段的開發模式。兩者相關，但並非同義：採用 SDLC 不表示一定要採用瀑布法，SDLC 也能結合敏捷、原型或 DevOps 等做法。

解題方法

可從「需求穩定度、外部依賴、交付速度、治理要求」四個面向判斷：

1. 需求穩定度：若功能、流程及驗收標準已明確，且短期內變動少，依序規劃與驗收較容易。
2. 外部依賴：API 的功能、費率、服務品質及介面可能由供應商調整，整合時常須透過實際呼叫與測試確認假設。
3. 交付速度：若機關需要先驗證民眾或承辦人員是否真正需要該服務，分階段推出小型可用版本，通常比等待完整系統更能及早取得回饋。
4. 治理要求：公部門仍須管理資安、個資、權限、稽核、採購、紀錄保存及服務持續性。採用較彈性的開發方式，不代表可以省略這些控制。

因此，SDLC 的規劃、文件、測試與維護觀念仍適用；若把瀑布法當作唯一方法，要求所有需求在開發初期完全定案，則較不適合需求探索較多、依賴外部 API 且技術變動快速的專案。

替代方法與取捨

敏捷與迭代式開發

將系統拆成短週期工作，每一週期交付可展示或可使用的功能，再依使用者及業務單位回饋調整。機關可先完成登入、權限、基本問答流程，再逐步加入知識庫、審查機制與稽核功能。

**優點：**及早交付、較快發現需求落差，能因應 API 或使用情境變動。

**取捨：**需求持續變動時，範圍與成本較難一次固定；若欠缺文件、版本管理及驗收紀律，也會增加維護困難。敏捷開發須配合明確的優先順序、驗收條件及變更管理。

原型法與 MVP

原型法先製作簡化介面或流程，讓承辦人員實際操作並回饋；最小可行產品（Minimum Viable Product, MVP）則先提供範圍受控、能驗證核心需求的正式功能，再根據使用結果逐步擴充。

**優點：**適合檢驗需求及使用方式，可避免投入大量資源後才發現服務設計不合用。串接 AI 時，也可先以有限資料及明確任務測試回答品質、失敗情形與人工覆核需求。

核心觀念

本題考查警政資訊系統的建置途徑比較與資訊計畫規劃推動。答題時要先提出三種可行方案，再依成本、時程、功能適配、資安維護與長期擴充等面向比較，最後選定一案，說明從需求盤點到上線維運的推動步驟。

**NFC（近場通訊）**是短距離無線通訊技術，員警以手機或專用讀取設備感應巡邏點的 NFC 標籤，系統記錄感應時間、地點、員警身分與巡簽結果，供勤務查核、異常通報及統計分析。巡邏標籤只是查核點，並不能單靠感應證明員警確實完成巡邏；系統仍須搭配身分驗證、異常偵測及抽查等措施。

本題涉及員警身分、勤務軌跡與巡邏紀錄等資料，規劃時應依命題當年（民國 112 年）法規及機關規範，檢視個人資料保護、警察勤務與資通安全要求，採取目的明確、資料最小化、權限控管、留存期限管理及稽核紀錄等措施。

解題方法

先把「取得和建置」拆成三條路徑：

1. 委外採購套裝系統：向廠商購買或租用既有產品，再依警察機關需求設定。
2. 修改既有公部門或警政系統：以現有勤務、身分驗證或行動警勤系統為基礎，增添 NFC 巡簽功能。
3. 自行開發或委外客製開發：由機關自行組成團隊開發，或委託廠商依需求製作專屬系統。

接著以同一組評估標準逐案比較，避免只寫「成本高低」而漏掉資安、整合與維運。第二小題則選擇一項方案，按「需求、可行性、採購或開發、試辦、驗收、推廣、維運」的順序提出計畫。

三種建置方案及利弊

方案一：採購套裝產品或委外建置

由機關訂定需求規格，採購具 NFC 巡簽、員警帳號管理、勤務後台及報表功能的產品；也可由廠商負責導入、教育訓練與維護。

優點：

• 可利用既有產品與經驗，建置時程通常較短。
• 初期不必由機關自行招募完整的軟體開發團隊。
• 廠商可提供設備、系統導入、教育訓練及後續維護服務。
• 適合需求明確、希望快速在多個單位推行的情形。

缺點：

• 套裝功能與警察勤務流程未必完全相符，客製需求會增加成本與時程。
• 系統架構、資料格式或維護方式若受廠商限制，容易形成廠商依賴。
• 若契約未明定資料歸屬、介接規格、原始碼或退出移轉機制，日後更換廠商困難。
• 必須嚴格管理廠商接觸資料的權限，並確認資料儲存、傳輸及備援方式符合機關資安要求。

方案二：擴充既有警政或公部門系統

盤點現有勤務管理、員警身分驗證、行動警勤或資訊平台，選擇適當系統增添 NFC 感應、巡簽紀錄與管理報表功能。

優點：

• 可沿用既有員警帳號、設備、網路及管理流程，減少重複建置。
• 有助於與勤務派遣、排班或其他警政資料整合，降低多套系統並行的負擔。
• 若既有平台已有成熟的資安與維運機制，可縮短新系統管理流程的建立時間。
• 使用者較熟悉既有介面與帳號，教育訓練負擔較低。

缺點：

• 既有系統可能使用老舊架構，擴充功能後增加維護與效能負擔。
• 既有系統的資料格式、介接方式或權限設計可能不適合巡邏查核需求。
• 新功能可能受到原平台廠商、系統規格或機關分工限制。
• 若系統原本並未設計為行動即時服務，離線補傳、設備管理與大量資料查詢都需要額外處理。

方案三：機關自行開發或委外客製開發

由機關成立專案團隊，先定義流程與需求，再自行開發，或委外依機關規格客製。機關負責系統需求、資料規則、驗收與後續治理。

優點：

• 能依實際勤務流程設計功能、權限與報表，需求適配度高。
• 可將資料介接、擴充彈性及跨單位使用納入架構設計。
• 由機關掌握需求與驗收標準，較能建立符合自身管理方式的系統。
• 若契約設計妥當，可要求開放介接規格、完整文件與資料移轉能力，降低廠商綁定。

缺點：

• 從需求分析、系統設計、開發到測試均需時間，初期建置成本與管理負擔較高。
• 機關須具備產品管理、資安審查、測試驗收與維運能力；委外開發也不代表機關可免除這些責任。
• 若需求訪談不足或使用單位未參與，容易發生功能與實際勤務不符、追加需求或延誤。
• 上線後仍須安排修補、版本更新、備援與故障處理，不能把建置完成視為專案結束。

三方案比較

評估面向	採購套裝／委外建置	擴充既有系統	自行或客製開發
建置速度	通常較快	視既有系統狀況而定	通常較慢
初期成本	中至高，依授權與客製程度而異	通常較低至中	中至高

核心觀念

本題考查個資外洩事件的原因分析與資安事件調查方法。判斷時須區分「資料被發現或販售的地點」與「資料最初外洩的來源」：暗網只是資料流通的管道，資料集名稱也不能單獨證明資料來自該名稱所指的機關或系統。

題幹指出，資料包含多種來源的資訊，且多年來流傳於暗網；因此應從資料蒐集、儲存、使用、傳輸、委外處理及人員管理等環節，檢視是否有多個外洩來源或資料遭到彙整的情形。調查結論須以資料特徵、系統紀錄及保管鏈等證據支持，不能只憑資料筆數、標題或媒體描述定案。

**法規基準：以命題當年（民國 112 年）法規為準。**依當時《個人資料保護法》，公務機關蒐集或處理個人資料須有特定目的並符合法定要件；公務機關保有個人資料檔案，應採行適當安全措施。《資通安全管理法》及其相關子法則要求適用機關建立資安事件通報與應變機制。現行《個人資料保護法》已修正，本文仍依命題年度說明。

解題方法

可依序採「確認資料真偽與範圍 → 追查資料來源與流通路徑 → 檢視可能失守環節 → 蒐集佐證並排除其他解釋」作答。

題目問的是「可能的原因」，不要求先認定某一機關已發生外洩。因此應列出合理的技術與管理成因，同時指出須用哪些資料驗證。題幹提到資料並非來自單一來源，作答時尤其要納入不同資料源遭整併、舊資料遭重新流通，以及資料與戶政資料遭錯誤連結或命名等可能性。

個資外洩事件可能原因

1. 系統遭未授權入侵 攻擊者可能利用弱密碼、未修補漏洞、錯誤設定、釣魚郵件或遠端存取弱點，取得資料庫、備份檔或管理者帳號，再將資料匯出或出售。

2. 內部人員或受託廠商不當存取 具合法權限的員工、維運人員或委外廠商，可能超出業務需要查詢、複製或攜出資料；也可能因權限過度集中、帳號共用或離職帳號未停用，使資料遭不當取得。

3. 系統或儲存設備設定錯誤 資料庫、雲端儲存空間、檔案伺服器、測試環境或備份設備若設為公開存取、缺乏存取限制，或使用預設帳密，可能使資料被直接下載。

4. 資料傳輸、備份或媒體管理不當 資料在機關與受託廠商、不同系統間傳送時，若未加密或未妥善驗證接收端，可能遭攔截或誤寄。備份光碟、硬碟、筆電或紙本遭遺失、竊取，也可能造成外洩。

5. 跨來源資料遭彙整或再識別 個別資料集未必單獨包含完整身分資訊；但不同來源的姓名、地址、出生日期、身分證字號等欄位遭比對、合併後，可能形成高識別性的資料庫。資料集因此被冠上「戶政資料」名稱，不等於其內容全由戶政系統一次外洩。

6. 早期外洩資料重複流通 資料可能在過去某次事件中外洩，之後被複製、加工、重新包裝或多次販售。暗網近期出現或再次拍賣，只能說明資料再次流通，不能直接判定外洩發生時間。

核心觀念

本題考查資訊系統分類與整合型系統規劃。題目把多種能力放在同一套系統中：即時掌握物流車與交通狀況、查看業務細節，並依臨時任務快速建議派遣車輛。因此，應依系統的主要決策目的判斷主體類型，再說明其他類型在整體架構中扮演的角色。

本系統的主體是 DSS（Decision Support System，決策支援系統）：它整合即時資料與分析模型，協助主管或調度員選擇適合的車輛。地圖及空間分析屬 GIS 能力；車輛與任務的日常資料登錄、更新屬 OLTP；控制室儀表板呈現屬 EIS；歷史資料的統計與趨勢分析則屬 Data Analytics。這些能力可以共存於同一解決方案，不必把系統硬歸成單一技術。

解題方法與類型判斷

判斷系統類型時，先看使用者要完成的核心工作，再看系統如何支援該工作：

1. 核心工作是派遣決策：收到臨時送貨任務後，系統要比較車輛的預計抵達時間等條件，提出適合的派遣對象，這是 DSS 的典型用途。
2. 地圖與位置是重要資訊呈現方式：系統需處理地理位置、路網、區域及交通資料，故需整合 GIS。
3. 同時涉及交易、監控與分析：日常任務及車輛狀態更新由 OLTP 支援；控制室的大螢幕可用 EIS 式儀表板呈現；歷史派遣績效與需求趨勢可由 Data Analytics 分析。

所以最恰當的主分類是 DSS，但完整方案是以 DSS 為決策核心，整合 GIS、OLTP、EIS 與 Data Analytics 的系統。

初步需求與解決方案

一、初步需求

需求訪談應確認下列事項：

• 使用者與流程：調度員、主管及車隊管理者的權限；臨時任務如何提出、審核、派遣、回報及結案。
• 車輛與任務資料：車輛位置、行駛狀態、載重或容量、可服務區域、目前任務起訖點、任務優先級與交付時限。
• 交通與地圖資料：管轄區域底圖、道路與路網、即時交通狀況、道路限制及資料更新頻率。
• 派遣規則：預計抵達時間、距離、車輛容量、任務優先級、司機工時或其他營運限制如何加權或設定門檻；最終由系統建議或自動派遣。
• 非功能需求：定位與交通資料的時效、系統可用性、畫面更新速度、尖峰負載、資安與個資保護、操作紀錄、備援及災難復原需求。

二、所需技術項目

1. 資料蒐集與傳輸：車載 GPS／行動裝置回傳位置與狀態；透過安全的行動網路或 API 傳輸。
2. GIS 與地圖服務：地圖圖磚、地理資料庫、座標轉換、路網分析及路線估時；串接交通資料來源。
3. 後端服務與資料庫：以 API 接收任務及車輛狀態，交易型資料庫支援 OLTP；地理空間資料可由具空間索引能力的資料庫管理。
4. 即時處理與訊息傳遞：以訊息佇列或事件串流處理大量位置更新，降低前端與資料庫直接承受的瞬時負載。