108 高普考高考三級 資訊處理 系統專案管理 考古題詳解

核心觀念

本題考查需求訪談與需求蒐集的結構化提問。$5W1H$ 是以六個基本面向整理問題的方法：Who（誰）、What（什麼）、When（何時）、Where（何地）、Why（為什麼）、How（如何）。它能協助訪談者從不同角度理解使用者、作業情境與現行流程。

本題不涉及特定法條或公式。

解題方法

先確認訪談目的是了解民眾購買北迴線車票的情境與流程，再依 $5W1H$ 六個面向逐一設計開放式問題。問題應聚焦於民眾實際的購票經驗，避免只問「是否方便」等容易得到簡短回答的問題。

（一）訪談為什麼要運用 $5W1H$？

$5W1H$ 可將訪談內容有系統地涵蓋人物、事項、時間、地點、動機與方式，降低只從單一角度提問而遺漏重要資訊的風險。透過六個面向，訪談者能較完整地了解：

• 誰是購票者或相關人員，以及其需求與角色。
• 購買什麼車票、要完成哪些作業。
• 何時購票、搭乘，以及流程各階段的時間。
• 在何處購票、取票及搭車。
• 為何選擇該路線、車種或購票方式。
• 如何查詢、付款、取票與處理異常。

因此，$5W1H$ 有助於蒐集完整、可整理且便於後續分析的需求資訊，也能作為訪談者檢查問題是否周全的架構。

（二）以 $5W1H$ 設計訪談問題

核心觀念

本題考查系統分析師在系統開發生命週期中的角色與工作範圍。系統分析師是連結使用者、管理者與技術團隊的專業人員，負責了解組織問題與需求，將需求轉化為可設計、開發、測試及維護的系統規格，並協調各方確保系統符合業務目標。

以新陶市消防機關的指揮派遣平台為例，系統分析師不只撰寫需求文件，也須參與設計、測試、上線與營運維護；各階段工作相互銜接，確保平台支援報案受理、案件派遣、車輛與人員狀態管理、資訊交換及服務持續運作。

解題方法

依題目指定的五個階段逐一作答，並以「工作目的＋消防派遣情境中的具體工作」說明。每一階段都應展現系統分析師如何將使用者需求轉化為可執行的系統工作，避免只列抽象名詞。

（一）系統分析（5 分）

系統分析的目的，是確認問題、使用者需求及系統範圍，形成後續設計與開發的依據。系統分析師可負責：

1. 訪談並蒐集需求：訪談勤務指揮中心、消防分隊、救災人員、資訊人員及管理者，了解報案受理、案件分級、派遣、回報與結案流程。
2. 描繪現行作業與問題：整理現行流程及資料傳遞方式，找出重複輸入、資訊延遲、案件狀態不一致或跨單位通報不易等問題。
3. 界定系統範圍與需求：列出功能需求，例如案件建檔、地址定位、派遣建議、車隊狀態更新及勤務紀錄；也確認非功能需求，如可用性、回應速度、資安、備援及操作易用性。
4. 建立需求模型與文件：以流程圖、資料流程圖、使用案例或需求規格書描述系統與外部使用者、其他系統的互動。
5. 確認需求與優先順序：與利害關係人確認需求正確性、優先級及驗收條件，並處理彼此衝突的作業要求。

（二）系統設計（5 分）

系統設計是依據已確認的需求，規劃系統如何實作。系統分析師可負責：

1. 規劃系統架構與模組：將平台劃分為案件管理、派遣決策、地圖定位、車輛狀態、通知通訊及報表等模組，規劃模組間的責任與介面。
2. 設計資料結構與資料庫：定義案件、報案人、地點、派遣單位、車輛、人員與勤務紀錄等資料及其關聯，並規劃資料存取權限與稽核紀錄。
3. 設計操作介面與流程：依勤務人員的工作情境設計操作畫面及步驟，例如在派遣台快速查看案件地點、可用車輛、派遣狀態及回報資訊。
4. 設計系統介接與安全機制：規劃平台與地圖、通訊或其他相關系統的資料交換方式，並設計身分驗證、權限控管、傳輸保護及備份機制。
5. 撰寫並確認設計規格：將架構、資料、介面、流程與安全需求整理成設計文件，與開發及使用單位確認可行性及符合需求程度。

（三）系統測試（5 分）

系統測試的目的，是確認系統功能與品質符合需求，並能在預定環境下穩定運作。系統分析師可負責：

核心觀念

本題考查敏捷式開發的精神，以及測試驅動開發、持續集成與重構三項常見實務。答題時應先說明敏捷式開發如何因應需求變動，再分別解釋三項實務，並將每項落到「上車鈴」APP 的開發情境。

解題方法

先以「短週期、可運作成果、持續回饋與調整」說明敏捷式開發，再用「先寫測試、頻繁整合程式碼、改善內部結構」區分三項實務。舉例應具體連結銀髮使用者、站牌 QR Code、公車司機通知及到站提醒等需求。

（一）敏捷式開發（Agile Development）

敏捷式開發是一種以迭代與增量方式進行軟體開發的方法。團隊將產品需求拆成較小的功能項目，分階段完成並交付可運作的軟體；每次迭代都透過測試、展示與利害關係人回饋，檢視成果並調整後續工作。

敏捷式開發重視：

• 回應變更：需求或使用情境改變時，團隊能調整產品待辦事項與開發優先順序。
• 頻繁交付：先交付具價值的功能，逐步增加系統能力。
• 合作與回饋：開發團隊與使用者、業務單位等利害關係人持續溝通。
• 品質內建：透過測試、持續整合及重構，維持軟體品質與可維護性。

以本案而言，可先開發「掃描站牌 QR Code 後，通知指定路線公車司機本站有人候車」的基本功能，再依銀髮市民試用意見，逐步改善字體大小、操作步驟、語音提示，以及乘客收到公車到站提醒的方式。每個階段都交付可展示或試用的成果，據以調整下一階段需求。

（二）三項敏捷式開發實務

1. 測試驅動開發（Test-Driven Development, TDD）

測試驅動開發是先依功能需求撰寫自動化測試，再撰寫程式使測試通過，最後整理程式結構。常以「紅、綠、重構」描述：

1. 紅：先寫一個尚未通過的測試，明確定義預期行為。
2. 綠：撰寫足以讓測試通過的程式。
3. 重構：在測試持續通過的前提下，改善程式設計。

核心觀念

本題考查資訊系統轉換策略與系統上線風險管理。新舊系統雙軌並行（Parallel Conversion），是指新系統上線後，於一段過渡期間內，新舊系統同時運作並處理相同業務，再比對結果，確認新系統穩定且資料正確後，才正式停用舊系統。

本題不涉及特定法條或計算公式。作答時應從風險控制、公司決策限制，以及如何分階段完成轉換三個角度回答。

解題方法

依三小題分別處理：

1. 說明雙軌並行如何降低風險：指出舊系統提供備援，新系統則可在實際營運中驗證。
2. 分析公司當初不採雙軌的原因：從成本、作業負擔、技術相容性、資料與流程差異、時程及決策等面向提出合理理由。
3. 提出轉換建議：先盤點與測試，再分階段導入；以平行驗證及明確的切換、回復條件控制上線風險。

（一）為什麼新、舊系統雙軌並行可以避免風險過大？（5 分）

雙軌並行的核心，是在新系統尚未被證明足以穩定支援營運前，保留舊系統作為備援。其風險控制效果如下：

• 降低單點失敗風險：若新系統發生故障、效能不足或功能缺漏，仍可由舊系統維持重要業務，減少服務中斷。
• 驗證新系統的正確性：新、舊系統處理相同交易後，可比對保單、保費、理賠、帳務等資料，及早發現轉換錯誤或計算差異。
• 保護客戶權益：若錯誤影響保戶資料、保費或理賠處理，可在舊系統仍可運作時查核與補救，避免錯誤擴大。
• 保留回復空間：新系統未達預定標準時，可以暫停切換、修正系統，或將營運切回舊系統。
• 降低一次性切換衝擊：透過過渡期觀察尖峰負載、作業流程及使用者操作問題，避免所有業務同時承受未經驗證的風險。

因此，雙軌並行不是消除風險，而是透過備援、比對與回復機制，降低新系統問題對營運和保戶造成的衝擊。

（二）該公司當初未採取雙軌並行的可能原因（10 分）

站在公司角度，未採雙軌並行可能出於下列考量：

1. 成本過高：過渡期間須同時維護兩套系統，增加軟硬體、授權、維運及廠商支援費用。若新系統已投入大量建置成本，公司可能希望儘早停止舊系統支出。
2. 重複作業增加負擔：同一筆交易須在兩套系統登錄或核對，增加員工工作量，也可能因人工作業而產生新的輸入錯誤。
3. 新舊系統流程與資料結構不同：套裝企業系統可能重整既有流程、資料欄位及權限設計；舊系統資料未必能直接對應新系統，導致同步、比對與跨系統介接困難。
4. 架構或技術不相容：舊系統可能已難以維護，與新系統無法穩定並存；若兩系統共用資料或介接機制，並行期間也可能發生資料衝突。
5. 時程與資源壓力：公司可能受專案期限、合約時程、監理或營運規劃限制，認為無法負擔較長的並行期。
6. 認為測試已足以降低風險：管理階層可能相信前期測試、資料轉換及驗收已充分，因而認為直接切換較有效率。
7. 套裝系統導入帶來的決策期待：公司原本期待新系統整合系統與商業流程、提升銷售效率及客戶體驗，可能因此傾向一次切換，以儘早取得效益。