114 高普考高考二級 資訊處理 軟體專案管理研究 考古題詳解

核心觀念

範疇蔓延（Scope Creep）是指專案執行期間，未經正式審查與核准，工作內容或交付成果持續增加或改變，卻沒有相應調整時程、成本、人力及其他資源的現象。它通常源於需求逐步增加、變更管理不足或利害關係人對專案範疇認知不一致。

範疇蔓延與正式的範疇變更不同：變更若經評估影響、依程序核准，並同步更新基準與資源計畫，屬於受控的變更；未經管控便把新增事項納入工作，才是範疇蔓延。

解題方法

本題可依「定義範疇蔓延—說明成因—提出控管流程與措施」作答。控管重點不在一律拒絕新需求，而在讓每一項變更都經過記錄、影響分析、核准與基準更新，避免專案在資源不變的情況下承擔額外工作。

發生原因與例子

1. 需求未充分釐清：需求分析階段缺少使用者訪談或驗收條件。例如，系統原本只需提供月報，開發途中才陸續要求增加即時儀表板、歷史資料比較與多種匯出格式。
2. 利害關係人持續追加需求：使用者或主管把新功能視為「只要順便加上即可」，卻未理解其對成本與時程的影響。
3. 需求與範疇定義不明確：範疇說明、需求規格或工作分解結構（WBS）未清楚界定交付成果與排除項目，導致各方對專案包含哪些工作看法不同。
4. 變更管理程序薄弱：團隊接受口頭指示或直接修改工作，未留下變更紀錄，也未評估時程、成本、品質、風險與資源影響。
5. 高層或客戶繞過專案管理流程：直接要求團隊新增工作，使核准機制失去作用。
6. 團隊主動加做：開發人員未經需求確認便自行增加功能或規格，形成「鍍金」（Gold Plating）；這也會擴大專案工作，並帶來額外測試與維護負擔。

專案管理者的控管措施

核心觀念

本題考查人工智慧（AI）在專案管理中的輔助角色，以及 AI 如何補足敏捷與傳統專案管理各自的執行限制。作答重點不是列舉 AI 工具，而是依題目指定的三個面向，說明 AI 能提供什麼能力、改善什麼管理缺口，以及仍需由專案團隊承擔的判斷責任。

敏捷管理採短週期、迭代交付與持續回饋，能快速回應變化，但若缺乏整體可見性，可能難以掌握長期依賴關係、跨團隊資源與整體風險。傳統管理重視前期規劃、基準與階段管控，便於控管範疇、時程與成本，但在需求快速變動時，重新估算與調整計畫較不靈活。AI 可運用歷史資料、即時進度與工作紀錄，協助管理者更快取得資訊、辨識趨勢並比較方案。

解題方法

採「管理面向 → AI 能力 → 補足的限制」逐段作答，並在每段同時涵蓋敏捷與傳統專案管理。如此可直接回應題目所問的「三個面向」及「如何補足缺陷或限制」。

一、決策支援

AI 可整合需求文件、工作項目、會議紀錄、進度報告、缺陷資料與利害關係人回饋，協助摘要現況、辨識待決事項，並呈現不同方案對範疇、成本、時程及品質的影響。

• 補足敏捷的限制： 敏捷團隊通常以短週期與團隊協作快速決策；當資訊散落在待辦清單、討論紀錄與多個團隊之間時，容易缺少整體視角。AI 可彙整跨迭代資訊，協助產品負責人排序待辦事項、辨識需求變更影響，並支援跨團隊協調。
• 補足傳統管理的限制： 傳統專案依賴計畫基準與定期報告，資料更新或彙整較慢。AI 可根據最新進度與變更資訊，快速比較調整方案，讓管理者及早看見基準偏差及其可能影響。
• 管理上的價值： AI 提供分析與建議，管理者仍須依目標、契約、利害關係人需求與專業判斷作成決策；模型輸出不能取代責任歸屬與核准程序。

二、風險預測

AI 可分析歷史專案資料與目前執行訊號，例如工作項目延遲、缺陷增加、需求變更頻率、資源負荷或依賴工作未完成等，找出與逾期、超支或品質問題相關的模式，據以預測風險並提示早期警訊。

核心觀念

軟體重構（Refactoring）是指：在不改變軟體外部可觀察行為的前提下，調整既有程式碼的內部結構，使程式更容易理解、修改、測試與維護。重構通常以小步驟進行，並透過測試確認每一步都沒有改變原有功能。

本題考查三個面向：重構的定義與目的、常見重構方法，以及專案中適合進行重構的時機。重構的關鍵判準是「外部行為不變、內部品質改善」；若變更同時加入新功能或改變系統行為，就不只是重構。

解題方法

可依題目要求分成三部分作答：

1. 先定義重構：指出它是改善內部設計，且不改變外部行為。
2. 再說明目的並舉例：交代重構如何降低複雜度、改善可讀性與可維護性，並列出具體方法。
3. 最後說明導入時機：以「程式碼開始妨礙理解、修改或測試」作為主要判斷依據，同時說明應在測試保護下分階段進行。

重構的主要目的如下：

• 改善可讀性與可理解性：讓程式結構和命名更清楚，降低理解成本。
• 降低複雜度與重複程式碼：減少重複邏輯，使修改集中且一致。
• 提升可維護性與可擴充性：讓後續修正、除錯及新增需求更容易。
• 降低變更風險：透過明確的模組與責任分工，減少修改造成的連鎖影響。
• 改善測試性：讓模組較容易獨立測試，並利於建立自動化測試。

常見重構方法至少包括以下五種：

核心觀念

本題考查 DevOps 的核心理念，以及它如何改變軟體專案的管理方式與交付流程。DevOps 是 Development（開發）與 Operations（維運）的協作模式，透過文化、流程與自動化，縮短從需求變更到正式服務的時間，同時維持品質、穩定性與可追蹤性。

其核心觀念包括：

• 打破部門壁壘：開發、測試、維運及資安人員共同對服務品質與交付結果負責。
• 持續整合與持續交付：頻繁將程式變更整合至共用版本庫，透過自動化建置與測試驗證；通過檢核後可部署至測試或正式環境。
• 自動化與基礎架構即程式碼：以程式碼管理環境設定、部署與基礎設施，降低人工操作造成的錯誤，並讓環境可以重複建立。
• 持續監控與回饋：蒐集系統效能、錯誤與使用狀況，讓團隊及早發現問題並調整產品。
• 小批次、持續改善：以較小且頻繁的變更降低單次發布風險，並利用事後檢討改善流程。

DevOps 不只是購買工具或加快發布，也不是取消測試與變更控管；它是把開發、交付、部署及維運納入同一個持續回饋的管理循環。

解題方法

可依「定義與理念 → 專案管理影響 → 工具及應用」三部分作答。先說明 DevOps 如何整合開發與維運，再從時程、品質、風險、團隊協作及監控等面向分析管理上的影響，最後列出至少三項工具並說明其在流程中的用途。

對軟體專案管理的影響

• 時程與交付管理：自動建置、測試及部署可縮短交付週期，使專案能以較小批次提供功能，並較快回應需求變更。
• 品質與風險管理：自動化測試及一致的部署流程有助於及早發現缺陷、減少人工錯誤。小批次發布也較容易定位問題並回復版本。
• 團隊與溝通管理：開發與維運共同負責服務成果，能減少交接落差，並促進跨職能協作；管理者也需建立共同目標與明確責任。
• 監控與決策管理：透過日誌、指標及告警掌握服務狀況，讓團隊依實際資料調整優先順序與後續工作。
• 組態與變更管理：版本控制及基礎架構即程式碼讓變更較可追蹤、重現與稽核，但仍須設定權限、審核、測試及回復機制。