115 高普考高考三級 資訊處理 資訊管理 考古題詳解

核心觀念

需求變動管理是在需求改變時，控制其對專案範圍、成本、時程、品質與風險的影響。本題考兩種面對變動的核心策略：

• 變動預期（Change Anticipation）：預先辨識需求可能變動之處，透過規劃、分析與設計，降低變動發生時造成的衝擊。
• 變動容忍（Change Tolerance）：承認需求難以完全預測，讓開發流程與系統設計能以較低成本、較快速度吸收變動。

兩者的差異在於：變動預期重在「事前辨識與準備」；變動容忍重在「提高面對變動時的調整能力」。實務上可以依專案風險、技術特性與需求不確定程度併用。

解題方法

作答時先說明兩種策略各自如何面對需求變動，再分別列出相應方法。方法可從兩個層次整理：

1. 專案與流程層次：如何發現、評估、核准及安排需求變動。
2. 系統與開發層次：如何讓系統設計及開發流程容易配合變動。

變動預期：事前辨識並管理變動

變動預期適用於能預見需求可能調整，或變動影響重大、需要審慎控制的專案。其重點是提早找出變動來源與受影響範圍，評估影響後再決定處理方式。

可採用的方法如下：

• 需求訪談與利害關係人分析：訪談使用者、管理者及其他利害關係人，確認需求、優先順序與潛在衝突，並辨識容易變動的需求。
• 需求驗證與原型：透過原型、情境或使用者驗收確認需求理解是否正確，及早發現遺漏、誤解或不一致。
• 需求追溯與影響分析：建立需求與設計、程式、測試案例及交付成果之間的追溯關係；需求變更提出後，據以分析影響的功能、成本、時程、品質與風險。
• 正式變更控制：將變更提出、記錄、分析、審查、核准或駁回及版本更新納入流程，由指定的權責人員或變更控制機制管理。
• 需求優先排序與基準管理：明確區分必要需求與較低優先需求，設定需求基準；變更時重新評估工作範圍及交付順序。
• 風險管理與預留資源：針對高變動需求預先評估風險，安排時程或資源緩衝，降低未預期變動造成的延誤。

核心觀念

資料治理是組織對資料進行管理與監督的整體架構，涵蓋決策權責、政策標準、作業流程及支援技術，使資料具備可用性、完整性、一致性、安全性與可追溯性。其目的不只是整理資料，而是讓資料能被可信地運用於營運、管理與決策，進而成為高價值的知識資產。

本題以「組織與人員、政策與標準、流程、技術與工具」四個構面，說明如何將治理制度落實到日常工作。四者須相互配合：人員負責與承擔，政策訂定規則，流程落實規則，技術支援執行與監控。

解題方法

可依四構面逐一回答，並說明各自的成功關鍵。作答時不宜只列系統或工具名稱；應同時交代誰負責、遵循什麼規則、如何執行，以及如何確認成效，才能呈現完整的治理建置方案。

四構面說明

一、組織與人員：建立責任、授權與協作

1. 取得高階主管支持：由高階主管擔任治理倡議者，提供資源、授權並處理跨部門歧見，使資料治理成為組織管理工作，而非資訊部門單獨負責的系統專案。
2. 建立治理組織與角色：設置資料治理委員會或治理團隊，明確分工。例如：

• 資料擁有者（Data Owner）：對資料的定義、使用目的及品質負責，通常由業務單位主管擔任。
• 資料管理人（Data Steward）：協調資料定義、品質維護、分類與日常管理。
• 資料保管者（Data Custodian）：由資訊或技術單位負責資料儲存、備份、存取控制及平台維運。

3. 促進跨部門協作與培訓：治理須連結業務、資訊、法遵及資安等單位；透過訓練與溝通，使人員了解資料定義、使用責任與作業方式，建立共同的資料文化。

二、政策與標準：訂出一致且可執行的規則

1. 制定資料治理政策：明確規範資料的權責、使用目的、存取權限、保存期限、分享方式及異常處理原則。
2. 建立共同標準與定義：統一重要資料項目的名稱、格式、代碼、分類及業務定義，並維護資料字典與中繼資料，使跨部門對同一資料有一致理解。
3. 納入品質、隱私與安全要求：設定資料品質標準及衡量指標，並將個人資料保護、機敏資料分級、最小權限及稽核要求納入政策；依適用法規與組織需求，明定合規責任。
4. 建立例外與更新機制：政策應指定核准權責、違規處理方式及定期檢討程序，並隨業務與法規需求調整，避免標準只存在文件中。

三、流程：讓規則進入資料生命週期

核心觀念

本題考查政府機關的營運持續管理：如何先評估中斷對業務的影響，再把業務需求轉成可用於復原規劃與演練的時間及資料目標。核心關係是：BIA 分析業務影響並辨識復原需求；MTPD、RTO、RPO 則分別描述可容忍的中斷上限、服務復原時限與可接受的資料回復點。

本題未要求特定法條，重點在業務持續管理與災害復原的基本定義。

解題方法

可先分辨各指標所回答的問題：

• MTPD：業務最多能中斷多久？
• RTO：事件發生後，必須在多久內恢復業務或服務？
• RPO：資料最多能回復到多早以前，也就是最多能承受多少資料損失？

解題時先說明 BIA 的分析對象與目的，再逐一說明指標，最後整理其時序及彼此限制。如此可避免把 RTO 與 RPO 都誤解成「服務恢復所需時間」。

業務衝擊分析（BIA）

業務衝擊分析是系統性分析中斷事件對組織業務活動、產品或服務所造成影響的過程。它會評估中斷時間拉長後的影響，例如對民眾服務、法定職責、財務、聲譽、資訊安全或其他關鍵業務的衝擊，並據此判定業務優先順序與復原需求。

BIA 常見工作包括：

1. 辨識重要業務活動及其相依的資訊系統、人員、資料、設施與外部供應者。
2. 分析不同中斷期間可能造成的影響，找出影響達到不可接受程度的時間界線。
3. 排定業務復原優先順序，並訂定或支持訂定 MTPD、RTO、RPO 等需求。
4. 提供 BCP、DR 策略、資源配置與演練設計的依據。

BIA 著重於「中斷造成什麼業務影響，以及業務需要多快、以何種資料狀態恢復」；它不是單純的資訊設備盤點，也不等同於辨識威脅與發生機率的風險評估。

三項量化指標

最大容忍中斷時間（MTPD）

MTPD 是從業務活動或服務中斷開始起算，到中斷所造成的不利影響達到組織不可接受程度為止的最長時間。

例如某項核心服務中斷 6 小時仍可透過替代流程維持基本服務，但超過 24 小時會使法定作業或民眾權益受到不可接受的影響，則其 MTPD 可設定為 24 小時。

**用途：**界定業務不可逾越的中斷上限，作為復原優先順序、BCP／DR 方案設計與演練成敗判準的重要依據。實務上，RTO 必須短於 MTPD，才能在影響達到不可接受程度前恢復業務。

復原時間目標（RTO）

RTO 是從中斷事件發生起，組織預定在多長時間內恢復特定業務活動、產品或服務，或恢復所需資源的目標期限。

例如某系統的 RTO 設為 4 小時，表示演練或實際災害復原時，該系統支援的業務須在中斷後 4 小時內達到預定的恢復狀態。

**用途：**設定服務與資訊系統的復原時限，據以選擇備援架構、復原程序、人力與資源，也用於衡量演練是否符合業務需求。RTO 描述的是「多久內恢復」，不是「資料最多損失多久」。

復原點目標（RPO）

核心觀念

本題考查敏捷開發中的四項實務，重點在於理解它們如何透過團隊協作、持續改善與自動化，提升軟體品質、交付速度及維運穩定性。回答時可分別說明「做法」與「效益」，並注意各實務的責任範圍：

• 集成式所有權強調團隊共同負責程式碼。
• 重構強調改善內部結構而不改變外部行為。
• DevOps 強調開發與維運協作及持續交付。
• 結對編程強調兩位開發者共同完成同一項程式工作。

解題方法

本題是實務說明題，沒有計算或選項。作答時，每一項依「定義／做法 → 直接效益 → 管理或品質上的價值」展開，即可避免只列名詞而未回答效益。並可指出各方法之間的關聯：集成式所有權與結對編程改善協作，重構維持程式碼可修改性，DevOps 則延伸協作至部署與維運。

四項敏捷實務

（一）集成式所有權（Collective Ownership）

**意涵：**團隊成員共同對系統及程式碼負責，程式碼不被視為某位開發者的專屬領域。具備適當理解的成員可修改任何模組，以修正缺陷、配合新需求或改善設計；修改仍須遵守團隊的程式規範、測試及版本管理流程。

效益：

1. 降低知識集中在少數人身上的風險，避免人員請假或離職時造成維護瓶頸。
2. 讓團隊能依工作需求彈性分配任務，縮短等待特定負責人處理的時間。
3. 鼓勵成員共同維護整體品質，及早發現模組間的問題。

集成式所有權不是任意修改他人程式碼，而是團隊共享責任，並以測試、程式審查及溝通維持變更品質。

（二）重構（Refactor）

**意涵：**在不改變軟體外部可觀察行為的前提下，改善程式碼內部結構，例如移除重複程式碼、拆分過長的方法、調整模組責任或改善命名。重構通常搭配自動化測試，確認修改前後功能結果一致。

效益：

1. 提升程式碼可讀性與可理解性，降低後續維護的認知負擔。
2. 減少重複與過度複雜的結構，使新增需求或修正缺陷更容易。
3. 降低技術債累積，減少未來變更引發錯誤的機率。

重構不等於新增功能，也不以改變使用者所見行為為目的；其核心是改善內部設計，維持對外功能不變。

（三）開發運維（DevOps）