108 高普考高考二級 資訊處理 系統分析與設計研究 考古題詳解

核心觀念

本題測驗系統發展生命週期（SDLC）初期「專案啟動與規劃」（Project Initiation and Planning, PIP）階段中，專案規劃（Planning the Project）​的核心活動。此概念源自現代系統分析與設計經典權威架構（如 Jeffrey A. Hoffer, Joey F. George 與 Joseph S. Valacich 所著之 Modern Systems Analysis and Design）。

專案規劃之目的在於深入探討專案範疇、可行性、資源配置、時程安排與潛在風險，最終產出「基準專案計畫」（Baseline Project Plan, BPP）與「專案工作陳述書」（Statement of Work, SOW），作為後續系統分析、設計與實作階段的衡量基準與管理依據。

---

解題方法

本題為高普考與高考二級極為標準的「名詞列舉與深入申論」題型。解答時應掌握下列層次：

1. 結構化分類：專案規劃的活動彼此具備邏輯相依性，切入點應依「範疇界定 $\rightarrow$ 任務與資源配置 $\rightarrow$ 流程與環境標準化 $\rightarrow$ 風險預算控制 $\rightarrow$ 基準計畫整合」的演進順序逐項展開。
2. 三要素答題原則：針對每一項活動，必須清楚交待「活動中文與英文標準名稱」、「核心工作內容與技術工具（如 WBS、PERT/CPM、甘特圖）」及「關鍵交付產出（Deliverables）」。

---

選項分析

本題為申論題，無選項設計。在公職閱卷標準中，本題滿分通常為 20 至 25 分，列出 10 項活動各佔 2 至 2.5 分。閱卷評分重點在於是否精確命中教科書標準名詞，若僅依個人工作經驗自創非標準名詞，或將後續系統分析階段之活動（如需求訪談、資料流程圖繪製）混入，將遭大幅扣分。

---

解題技巧

1. 四維記憶口訣（疇任資程、溝標風預、陳基）：

• 構想與結構：範疇可行性、任務拆解（WBS）。
• 時程與資源：資源估算、初步時程。
• 協同與控管：溝通計畫、標準程序、風險評估、預算編列。
• 產出與定案：工作陳述書（SOW）、基準專案計畫（BPP）。

2. 常考關鍵技術融入：在解釋各活動時，主動帶入相關專業工具，例如：

• 任務拆解帶出工作分解結構（WBS）。
• 時程安排帶出甘特圖（Gantt Chart）與關鍵路徑法（CPM/PERT），期望工期計算公式 $T_e = \frac{a + 4m + b}{6}$。
• 基準計畫帶出系統服務請求（SSR）與基準專案計畫（BPP）之關聯。

---

【答案】

在系統分析與設計的計畫規劃階段（Planning the Project），最常進行的十項活動及其詳細解釋如下：

1. 描述專案範疇、替代方案與可行性（Describing Project Scope, Alternatives, and Feasibility）

• 詳細解釋：明確界定系統的邊界、預期解決的問題及組織目標，確認系統應包含與不包含的功能範圍。同時，團隊需探討不同的替代架構或實作策略（如自行開發、採購現成軟體包、委外開發），並對各方案進行初步可行性研究（涵蓋經濟、技術、營運、時程與法律可行性），以確保專案具備推動價值。

2. 將專案拆解為可管理的任務（Dividing the Project into Manageable Tasks）

• 詳細解釋：利用「工作分解結構」（Work Breakdown Structure, WBS），將龐大複雜的系統專案由上而下逐層分解為具體、獨立、可明確指派負責人且易於追蹤的小型任務（Work Packages）。

核心觀念

本題評量的核心為系統開發生命週期（SDLC）​在「規劃與初期調查階段（Planning & Preliminary Investigation）」中，決定專案是否立案執行的關鍵門檻——可行性分析（Feasibility Study / Feasibility Analysis）。

可行性分析的目的是在投入大量資源之前，進行嚴謹的多構面風險評估，以協助管理階層進行「繼續／終止（Go / No-Go）」決策。在系統分析與設計的主流教科書（如 Shelly & Rosenblatt、Kendall & Kendall 等）與歷年國家考試命題架構中，最經典的分類為四大可行性（技術、經濟、作業、時程），而業界與進階理論常擴充為 TELOS 架構（涵蓋法律構面）或加入組織／政治可行性。

---

解題方法

回答本題應採取「破題定義 $\rightarrow$ 構面展開 $\rightarrow$ 深度剖析（定義、評估要素、工具方法）$\rightarrow$ 結論整合」的結構化切入點：

1. 破題定義：簡短界定可行性分析的目的與在 SDLC 中的角色（篩選計畫、資源配置、風險防範）。
2. 主要類別劃分：採用公職考試評分標準中最具代表性的五大構面（以 TELOS 框架為骨幹）：

• 技術可行性（Technical Feasibility）
• 經濟可行性（Economic Feasibility）
• 作業可行性（Operational Feasibility）
• 時程可行性（Schedule Feasibility）
• 法律／合規可行性（Legal Feasibility）

3. 細節論述：各類別必須包含「實質內涵」與「實務評估指標或工具」，不可僅給予名詞堆疊。例如經濟可行性須提及財務量化指標（NPV、ROI、回收期），技術可行性須提及技術風險與資源掌握度。

---

選項分析

本題為高考二級申論題，無選擇題選項。針對各評量類別的界線與易混淆點進行評析：

• 作業可行性 vs. 組織／政治可行性：部分文獻將「組織政治與文化」獨立為一類，但在經典架構中通常歸併於作業可行性。若答題時分開列出，可彰顯答題廣度；若合併，則須在作業可行性內強調「抗拒變革（Resistance to Change）」與「管理階層承諾」。
• 技術可行性 vs. 資源限制：技術可行性不僅評估「技術是否存在於世界上」，更強調「本專案團隊與委外廠商是否具備駕馭該技術的能力與經驗」。
• 經濟可行性 vs. 預算限制：經濟可行性不等於「預算是否足夠」（這是財務調度問題），而是評估「投入的成本能否換取預期的有形與無形價值（投資效益比）」。

---

解題技巧

1. 記憶口訣「TELOS」：

• T - Technical（技術）
• E - Economic（經濟）
• L - Legal（法律）
• O - Operational（作業）
• S - Schedule（時程） 考試時只要默寫出 TELOS 縮寫，便能確保五大面向完整涵蓋、不漏答。

2. 三段式闡述範式： 每一類別均依「定義核心 $\rightarrow$ 關鍵自問問題（Key Questions）$\rightarrow$ 採用工具／衡量標準」進行條列，此形式層次分明，閱卷委員可快速捕捉得分關鍵字。
3. 展現量化工具與管理知識：

• 經濟可行性提及：$ROI$、淨現值（$NPV$）、損益平衡分析（Break-Even Analysis）。
• 時程可行性提及：甘特圖（Gantt Chart）、關鍵路徑法（CPM/PERT）。
• 作業可行性提及：變革管理（Change Management）、使用者接受度測試（UAT）。

---

【答案】

評量資訊系統專案可行性（Feasibility Analysis）的目的，在於於系統開發生命週期（SDLC）初期，評估專案能否在組織限制下順利完成並產生預期效益，作為管理決策者執行「Go / No-Go」的依據。

影響判斷計畫可行性的主要類別包含下列五大構面（即國際通用的 TELOS 分析架構）：

一、 技術可行性（Technical Feasibility）

1. 定義：評估現有之資訊技術、硬體架構、軟體工具及專案團隊的技術能力，是否能有效支援新系統的開發與建置。
2. 主要評估要素：

• 技術成熟度與複雜度：評估擬採用的新技術（如微服務、雲端原生架構、AI 演算法）是否已穩定成熟，或是屬於先導性技術。
• 團隊技術能力（Technical Expertise）：專案團隊目前是否具備足夠的開發技能與架構設計能力；若不足，外部訓練或委外顧問的取得難易度為何。

核心觀念

本題的核心考點為資訊系統開發中的​「經濟可行性評估（Economic Feasibility Analysis）」​與​「整體擁有成本（Total Cost of Ownership, TCO）」​之成本分類。

在經典系統分析與設計（如 Jeffrey A. Hoffer、Joey F. George 與 Joseph S. Valacich 所著之《Modern Systems Analysis and Design》）理論中，系統生命週期的成本結構主要區分為兩大範疇：

1. 一次性成本（One-time Costs / Development Costs）：指系統開發建置階段所投入的資本支出。
2. 經常性成本／營運與維護成本（Recurring Costs / Operational and Maintenance Costs）：教科書標準定義即為題幹英文原句：「all costs associated with ongoing use and maintenance of a system」（指系統上線後，在整個運作生命週期中持續產生之維運、演進與使用支出）。

$TCO = \text{一次性開發成本 (One-time Costs)} + \sum_{t=1}^{n} \frac{\text{經常性維運成本}_t \text{ (Recurring Costs)}_t}{(1 + r)^t}$ （其中 $r$ 為折現率，$n$ 為系統預期運作年限）

---

解題方法

本題題幹中文提及「完整開發計畫所需要的支出」，但在英文括弧中特別限定並指明了定義：(all costs associated with ongoing use and maintenance of a system)。

此為國家考試命題教授直接引錄自英文權威教科書之原文定義。解題切入點應採取「以精準呼應題幹限定為主，宏觀涵蓋生命週期為輔」的策略：

1. 破題界定：明確指出題幹括弧英文定義即專指系統生命週期中的​「營運與維護支出（經常性成本，Recurring / Operational Costs）」。
2. 主體展開：針對該定義所涵蓋之核心項目逐一列舉並申論（包括應用軟體維護、硬體與授權更新、資料與儲存成本、通訊與網路費用、耗材與日常營運、持續性人員訓練與技術支援）。
3. 架構完整化：補述其與「一次性開發成本（One-time Costs）」之對照，展現考生對系統整體擁有成本（TCO）全貌的理解，確保閱卷委員無論採嚴格定義（括弧限定之營運維護費）或字面廣義（完整計畫之各階段成本）皆能給予滿分。

---

選項分析（題型與範疇辨析）

本題為申論題，非選擇題。作答時須在腦中釐清各項支出的範疇歸屬，避免混淆以下維度：

• 資本支出（CAPEX）vs. 營運支出（OPEX）： 一次性購置伺服器、機房改建屬資本支出；租用雲端基礎設施（IaaS/PaaS）、軟體訂閱（SaaS）及日常維護合約則轉為營運支出。現代系統分析特別重視 OPEX 在營運階段的長期支出。
• 固定成本（Fixed Costs）vs. 變動成本（Variable Costs）： 軟體年約授權為固定支出；網路流量頻寬費、雲端運算儲存依使用量計費者為變動支出，二者皆屬於 ongoing maintenance 的重要評估項目。
• 軟體維護的四種類型（IEEE/ISO 標準）： 在說明「應用軟體維護支出」時，若能進一步點出更正性（Corrective）、適應性（Adaptive）、完善性（Perfective）與預防性（Preventive）維護，可展現專業深度。

---

解題技巧

1. 掌握題眼與英文線索：遇有中英文夾雜之題目，務必優先檢視英文專有名詞或引文。本題的關鍵在於*(ongoing use and maintenance)*，若只回答「系統分析人事費、程式撰寫費」，將與引文定義嚴重偏離而遭扣分。
2. 答題結構化（人、機、軟、法、環）：列舉項目切忌雜亂，可依「軟體維護、基礎設施（硬體/雲端/網路）、人員與組織支援、消耗性與行政開銷」四個向度分點條列，標題明確並加粗標示。
3. 點出業界常態指標：在結論或說明中加註「根據軟體工程統計，營運與維護成本通常佔系統整體生命週期總成本（TCO）的 $60\%$ 至 $80\%$」，此數據為資訊處理類科之加分關鍵。

---

【答案】

在資訊系統的經濟可行性評估（Economic Feasibility）中，評估系統生命週期的整體擁有成本（Total Cost of Ownership, TCO）​是核心工作。

核心觀念

本題旨在測驗軟體工程與系統分析中原型模型（Prototyping Model）​的核心概念與生命週期劃分。原型法主要分為兩大派流：進化原型（Evolutionary Prototyping，又稱演化型原型）​與拋棄式原型（Throwaway Prototyping）。

進化原型的核心定義為：

1. 疊代與增量演進：系統開發始於對核心且明確之需求的理解，迅速實作一個可運作的初始原型（Initial Prototype）。
2. 原型即為最終產品的基底：與拋棄式原型（僅作為釐清需求的溝通媒介，確認後即捨棄重寫）截然不同，進化原型的程式碼與架構會直接保留，透過多輪「展示 $\rightarrow$ 使用者評估 $\rightarrow$ 修改擴充」的疊代過程，持續吸收新需求與細部功能，最終直接演化蛻變為上線運作的正式系統（Operational System）。

---

解題方法

解答申論題型之「過程圖與說明」時，應採三段式切入法：

1. 繪製標準流程圖（Process Flowchart）：清晰展現「起點 $\rightarrow$ 核心活動 $\rightarrow$ 判斷節點 $\rightarrow$ 疊代反饋迴路 $\rightarrow$ 終點」，符合系統分析之控制流規範。
2. 按階段逐項說明：將圖中每一個活動方塊拆解，詳述其輸入、主要工作內容與產出。
3. 深入闡述技術特性與關鍵成敗因素：說明進化原型的核心演化機制、適用情境，並輔以其與拋棄式原型的本質差異及實務風險，突顯高考二級所需的作答深度。

---

選項分析

本題為高考二級之申論題，非選擇題，故無選項分析。作答關鍵在於圖形完整性、階段說明的條理性，以及對「程式碼保留並持續演化」這一特質的精準定位。

---

解題技巧

1. 閱卷給分關鍵——迴路與終點：

• 繪製流程圖時，必須包含一個明確的決策菱形（「使用者是否滿意／系統是否完備？」）。
• 若未達標準，「回饋箭頭（Feedback Loop）」必須拉回至需求修正與原型精煉階段，不可拉回最初的空白起點。
• 終點節點必須標註為「交付／演化為正式系統」，而非「重新撰寫程式碼」。

2. 常見失分陷阱：

• 混淆兩大原型：許多考生誤將進化原型畫成拋棄式原型（在使用者滿意後接「依規格重新分析設計開發」），此為致命錯誤。進化原型是「以原型為基底逐步擴充至完成」。
• 過度簡化：僅畫三個框就交差。高考二級評分標準嚴謹，圖中應至少包含「初始需求定義」、「建立初始原型」、「使用者評估」、「修改與擴充原型」、「終止判斷」等關鍵節點。

3. 記憶口訣：

• 「定需求、建雛型、測反應、再精煉、成正果」。

---

【答案】

一、進化原型（Evolutionary Prototyping）過程圖