110 關務升官等考試薦任 技術類（選試系統分析） 系統分析 考古題詳解

核心觀念

本題考查系統分析的兩種方法：雛型分析法（Prototyping）與物件導向分析法（Object-Oriented Analysis, OOA）。兩者並非互斥的替代方案：雛型分析法著重透過快速建立模型，逐步釐清使用者需求；物件導向分析法則著重以物件、類別及其互動來描述問題領域，並形成後續設計與建置的依據。

解題方法

作答時，可分別從「定義與作法」、「優點與限制」及「適用時機」說明兩種方法，最後比較兩者的著眼點。尤其要避免把雛型當成正式成品，也不要把物件導向分析和物件導向設計、程式實作混為一談。

一、雛型分析法

內涵與作法

雛型分析法是先快速建構系統的簡化模型，讓使用者實際操作或檢視，再依回饋修正需求與設計。它的重點是以可觀察、可討論的模型，協助使用者和分析人員釐清原先不明確的需求。

典型流程如下：

1. 確認初步需求：整理使用者的目標、主要功能及尚未釐清之處。
2. 快速建立雛型：製作畫面、報表、操作流程或有限功能的初步版本。
3. 使用者評估與回饋：由使用者試用或檢視，指出不符合實際工作的地方。
4. 修正需求與雛型：依回饋調整功能、介面或流程，必要時重複評估。
5. 確認需求並進入後續開發：將已確認的需求轉化為正式規格，再進行系統設計與建置。

雛型可分為兩種常見形式：

• 拋棄式雛型：用來探索或確認需求，確認後即拋棄，正式系統另依規格建置。
• 演進式雛型：以雛型為基礎持續增加與改善功能，逐步形成可交付的系統。

兩者的差異在於雛型是否會成為正式系統的演進基礎；無論採哪一種，都應清楚界定雛型的目的，避免把為求快速展示而採用的簡化設計直接沿用到正式系統。

優點與限制

雛型可讓使用者較早看到系統概貌，減少需求文件與使用者實際期待之間的落差；對介面、操作流程及需求尚未明確的部分，也有助於及早發現問題。

限制則包括：使用者可能把雛型誤認為完成品，因而期待過快交付；反覆修改可能使範圍擴大；若只重視畫面展示而忽略資料、效能、安全性與系統架構，雛型也可能形成不良的正式系統基礎。

適用時機

適合用於：

• 使用者需求不明確、各方對需求理解不一致，或需求變動頻繁的系統。
• 使用者難以只憑文字規格想像操作方式的系統。
• 使用者介面、報表、工作流程等需要透過實際操作才能評估的部分。
• 需要及早取得使用者回饋、降低需求誤解風險的專案。

若需求穩定、功能規格明確，且系統具有嚴格的安全、效能或可靠性要求，雛型仍可用於探索需求，但不能取代完整的規格分析與正式設計。

二、物件導向分析法

內涵與作法

物件導向分析法是從問題領域出發，辨識其中的物件及其責任、屬性、行為和彼此關係，據以建立系統的分析模型。物件代表具有明確意義的事物或概念，例如「考生」、「報名資料」或「考試場次」；類別則是具有共同特徵之物件的抽象分類。

核心觀念

本題考查結構化方法（structured approach）的三個層次：結構化分析說明「系統要做什麼」；結構化設計說明「系統如何組織成可實作的架構」；結構化程式設計則說明「如何以清楚、可控制的程式邏輯實作設計」。三者由需求逐步走向程式實作，並以模組化、分解與明確表示降低複雜度。

結構化方法不是單一圖表或工具，而是一組有系統的分析、設計與程式撰寫技術。分析階段著重描述資料如何流動與轉換；設計階段將分析模型轉換為軟體架構與模組規格；程式設計階段則以具明確控制結構的程式碼完成各模組。

解題方法

依照「做什麼 → 如何組織 → 如何撰寫」的順序，分別說明每種技術的目的、主要工作及常用工具。工具名稱之外，也要交代它們如何協助表達需求、架構或程式邏輯，才算完整回答「內涵及其使用的相關工具」。

一、結構化分析（Structured Analysis）

內涵

結構化分析是以系統的功能與資料需求為中心，將複雜系統逐層分解，描述外部環境如何與系統互動，以及輸入資料如何經由處理轉換為輸出。分析者重點在建立邏輯模型，說明系統應完成的工作，不預先限定實際採用的硬體、程式語言或技術架構。

分析工作通常包括：

1. 界定系統範圍，辨認外部實體與系統間的資料交換。
2. 將高階功能逐層分解為較小的處理程序。
3. 描述各處理程序的輸入、輸出、資料來源及資料儲存需求。
4. 檢查圖表與文字規格是否一致，確認資料流與處理程序定義完整。

相關工具

• 資料流程圖（Data Flow Diagram, DFD）：以外部實體、處理程序、資料流及資料儲存庫呈現資料如何進入系統、被處理、儲存及輸出。可由環境圖或情境圖開始，逐層展開成較詳細的 DFD。
• 資料字典（Data Dictionary）：集中定義資料流、資料儲存庫及資料元素的名稱、內容、格式與結構，避免同一資料在不同圖表中有不同解釋。
• 程序規格（Process Specification, Mini-spec）：說明 DFD 中較低層處理程序的內部邏輯；常以結構化中文、決策表或決策樹表達。
• 實體關係圖（Entity-Relationship Diagram, ERD）：描述資料實體及其關係，協助建立資料需求與資料模型。
• 狀態轉換圖（State Transition Diagram, STD）：表達系統或物件在不同狀態間，因事件發生而產生的轉換，適用於具有明確狀態行為的系統。

二、結構化設計（Structured Design）

內涵

結構化設計將結構化分析建立的邏輯模型，轉換為可實作的軟體設計。主要目標是把系統分解為適當的模組，並安排模組間的呼叫與資料傳遞，使系統容易理解、實作、測試、維護及修改。

設計時常遵循下列原則：

• 高內聚、低耦合：模組內的工作彼此相關；模組間的依賴與資料交換則盡量簡單。
• 逐層分解：由整體系統逐步細分為子系統、模組及次模組。
• 明確的模組介面：定義模組的輸入、輸出、責任與呼叫關係。

核心觀念

本題考查資訊系統專案管理的兩個面向：一是系統專案失敗的原因，二是專案經理為確保專案達成目標所負責的主要工作。作答時宜先從專案本身、組織與使用者、技術及管理等角度整理失敗原因，再依專案生命週期說明專案經理的工作。

題目未涉及特定法條、公式或計算；下列內容以資訊系統專案管理的一般原則作答。

解題方法

可用「失敗原因分類」與「專案經理職責分類」兩段作答。失敗原因部分，應涵蓋需求、範疇、資源、技術、溝通、風險與組織支持；專案經理工作則依規劃、組織、執行、監控及結案的管理脈絡說明，並點出專案經理須在時間、成本、範疇與品質間進行協調。

一、資訊系統失敗的可能原因

資訊系統專案的「失敗」不只指系統無法上線，也包括超出預算或期限、未滿足需求、品質不佳、使用者不採用，或上線後無法帶來預期效益。

1. 需求不明確或分析不足 使用者需求蒐集不完整、需求彼此矛盾，或未釐清業務規則與例外情境，會使系統功能與實際作業脫節。若未讓使用者及利害關係人充分參與需求確認，開發完成後便容易出現大量變更與返工。

2. 專案範疇界定不清 未明確界定交付成果、功能邊界及驗收標準，容易造成範疇蔓延（scope creep）。新增需求不斷納入，卻未同步調整時程、預算與人力，將使專案延誤或品質下降。

3. 規劃與估算失準 對工作量、技術難度、整合與測試所需時間估算不足，或未考慮採購、教育訓練、資料移轉及上線準備等工作，會導致時程與預算不切實際。過度樂觀的承諾也會使團隊在壓力下犧牲測試與文件品質。

4. 組織支持與治理不足 高階主管未提供明確支持，專案缺乏決策者或資源；部門間權責不清、優先順序衝突，或重大議題久未裁決，都會使專案無法取得必要人力、預算與業務配合。

5. 溝通與利害關係人管理不良 專案團隊、使用者、資訊部門、廠商及管理階層之間資訊不透明，容易造成認知落差與決策延誤。若只著重技術交付而忽略使用者參與，也會降低系統接受度。

6. 技術與系統整合問題 採用不成熟或不適合的技術、缺乏所需技術能力，或低估舊系統介接、資料品質、效能、資安與相容性問題，可能使系統無法穩定運作或無法與既有環境整合。

7. 人力與團隊管理不當 關鍵人員不足、流動率過高、角色分工不明，或團隊缺乏必要訓練與合作機制，會影響進度與成果。若過度依賴少數關鍵人員，也會提高專案中斷風險。

8. 風險管理不足 未及早辨識需求變更、技術障礙、供應商履約、資安、資料移轉等風險，或雖已辨識卻未安排因應措施，容易使問題擴大成進度、成本或品質危機。

核心觀念

本題考查系統架構中「處理工作如何分配」與「系統元件如何分層」。主從式架構著重於用戶端與伺服器之間的角色分工及服務關係；三層式架構則著重於表現層、應用邏輯層與資料層的職責分離。兩者不是互斥的架構：三層式系統可以採用主從式方式，讓各層部署在不同的用戶端或伺服器上。

解題方法

作答時先分別界定兩種架構，再比較它們適合的開發情境。比較時掌握兩個切入點：

1. 看架構描述的重點：主從式看請求與服務的角色關係；三層式看系統功能與職責的分層。
2. 看系統的規模與需求：依部署規模、使用者數量、維護需求、安全性與擴充性，判斷採用何種架構。

主從式（client-server）架構

主從式架構由用戶端（client）與伺服器（server）組成。用戶端提出服務請求，伺服器接收請求、執行服務並回傳結果。伺服器通常負責集中管理共享資源，例如資料、檔案、印表機或應用服務；用戶端則提供使用者操作介面，並可負責部分資料處理。

主從式架構是邏輯上的服務關係，不表示所有處理都必須集中在伺服器。依工作分配方式，可有不同型態：

• 厚用戶端（fat client）：較多應用程式邏輯與處理工作在用戶端執行，伺服器主要提供資料或共享服務。
• 薄用戶端（thin client）：用戶端主要負責呈現與輸入，較多處理工作由伺服器完成。

其優點是可集中管理資料與共享資源，使用者也能透過用戶端存取伺服器服務。缺點是伺服器可能成為效能瓶頸或單點故障，且用戶端與伺服器間的連線品質、服務部署及版本維護都會影響整體運作。

三層式（three-tier）架構

三層式架構將應用系統依職責分為三層：

1. 表現層（presentation tier）：負責與使用者互動，包括畫面呈現、資料輸入與操作結果顯示，常見形式為桌面程式、瀏覽器或行動應用程式。
2. 應用邏輯層（application／business logic tier）：負責業務規則、流程控制、資料驗證及應用服務，接收表現層的請求，處理後再與資料層互動。
3. 資料層（data tier）：負責資料的儲存、查詢、更新與管理，通常由資料庫管理系統提供服務。