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

核心觀念

本題比較五種系統開發方法論在六項條件下的適用性，重點是掌握各方法如何安排需求分析、設計、建置與交付，以及這些安排對風險、時程和進度可見度的影響。

• 瀑布式開發法：依序完成分析、設計、建置、測試與交付，各階段主要以前一階段的成果為基礎。
• 平行式開發法：先完成整體分析與設計，再將系統切分為數個子系統，由多個團隊平行開發，最後整合。
• 階段式開發法：先規劃整體系統，再分階段交付可使用的版本；每階段增加一部分功能。
• 雛形法：先快速建立可操作的雛形，讓使用者試用並提供回饋，再反覆修正需求與系統。
• 極致程式設計法（XP）：屬敏捷方法，採短週期反覆開發，重視使用者持續參與、頻繁交付、測試與程式碼改善。

「進度可見度」是指開發期間能否定期看到可操作的成果；它與「開發時程壓力」不同，後者關注能否迅速交付。

解題方法

逐一對照六項準則與各方法的主要特性：

1. 需求明確時，可先完成完整規劃；需求不明確時，採用能快速取得回饋、調整需求的方法。
2. 技術不熟悉時，宜及早實作以驗證技術；技術成熟時，較能依既定計畫開發。
3. 系統越複雜，越需要整體設計與整合規劃；將系統切分成版本或子系統，可分散開發與交付風險。
4. 可靠度要求高時，需要完整設計、文件、測試與嚴謹控制變更。
5. 時程壓力大時，可考慮快速交付部分功能，或快速取得可用成果。
6. 重視進度可見度時，應選擇能定期展示或交付可操作成果的方法。

六項準則比較

準則	瀑布式開發法	平行式開發法	階段式開發法	雛形法	極致程式設計法（XP）
（1）使用者需求的釐清	需求須在前期充分釐清；需求穩定時適用，後續變更成本較高。	同樣需要前期完成整體需求與系統設計，才便於切分子系統。	能先依已知需求規劃整體，再逐階段補充功能；適合部分需求可先確定、部分可逐步明確的情境。	最適合需求不明確或使用者難以完整描述需求的情況，透過操作雛形與回饋逐步釐清。	需求可逐步形成，使用者代表持續參與並排列工作優先順序；需求變動可透過短迭代納入。
（2）技術的嫻熟度	適合技術成熟且開發團隊熟悉的環境；新技術風險較難提早由成品驗證。	可由不同團隊平行處理子系統，但整體架構與介面技術仍須掌握；技術不熟會增加整合風險。	適合技術大致成熟、能逐步交付的情況；每階段累積實作經驗。	適合技術或需求有不確定性時，以雛形快速驗證可行性；若把展示用雛形直接當正式系統，容易留下品質問題。	適合團隊能熟練運用自動化測試、重構、持續整合等技術實務的情境；技術不熟會使短週期開發更吃力。
（3）系統複雜度	適合複雜度可管理、且能在前期完成深入分析與設計的系統；整體依序開發。	適合可切分成相對獨立子系統的複雜系統；可平行開發，但須妥善處理介面與整合。

核心觀念

在系統開發生命週期（SDLC）初期的「系統規劃與可行性分析（Planning & Feasibility Analysis）」階段，必須針對候選系統方案進行「經濟可行性分析（Economic Feasibility Analysis）」，以評估專案在財務層面是否具備投資價值。

成本效益分析（Cost-Benefit Analysis, CBA）是經濟可行性分析的核心工具，其評估架構由兩大維度切分出四大類別：

1. 成本分類維度（時間週期性）：

• 開發成本（Development Costs）：專案建置期間發生的「一次性成本（One-time Costs）」。
• 作業成本（Operational Costs）：系統上線營運後持續發生的「經常性成本（Recurring Costs）」。

2. 效益分類維度（貨幣可量化性）：

• 有形效益（Tangible Benefits）：能夠明確以客觀財務數據或貨幣金額量化的經濟回報。
• 無形效益（Intangible Benefits）：對組織具長期策略價值，但極難以精準貨幣數值直接衡量的質性回饋。

後續通常配合財務衡量指標進一步決策，包括淨現值（Net Present Value, NPV，計算式為 $\text{NPV} = \sum_{t=0}^{n} \frac{\text{效益}_t - \text{成本}_t}{(1+r)^t}$，其中 $r$ 為折現率）、投資報酬率（ROI）及損益平衡點（Payback Period）。

---

解題方法

本題屬於標準申論題型，作答切入點應採「理論定義界定 $\rightarrow$ 本質特性說明 $\rightarrow$ 條列五項具體實務範例」之結構化鋪陳：

1. 定義界定：精準點出各類成本與效益的發生時點（建置期 vs. 營運期）及衡量屬性（可量化 vs. 質性）。
2. 範例列舉：避免空泛模糊的詞彙（例如僅寫「買電腦」、「賺錢」），應結合現代企業資訊系統（MIS/ERP/CRM/雲端架構）之生命週期支出與收益，展現高考二級應具備之實務專業度。

---

選項分析

本題為申論題，非選擇題，無個別選項分析。審題重點在於四大類別概念嚴謹互斥，不得相互混淆（如不可將一次性的初次教育訓練誤歸為作業成本，亦不可將具體的營收增加誤歸為無形效益）。

---

解題技巧

1. 二維矩陣記憶法：

• 成本看「時間頻率」：一次性建置付清 $=$ 開發成本；年年週期性付款 $=$ 作業成本。
• 效益看「度量衡」：財會報表能直接以新台幣入帳 $=$ 有形效益；心理感受、商譽形象、組織文化 $=$ 無形效益。

2. 常見陷阱與評分地雷：

• 陷阱一（訓練費用歸類）：系統導入時對種子使用者的「初次教育訓練」屬於開發成本；系統上線後每年對新進人員的常態訓練則屬作業成本。
• 陷阱二（軟體授權歸類）：傳統買斷式套裝軟體為開發成本；SaaS 訂閱制（如雲端年費）或每年原廠維護合約（SLA）則屬作業成本。
• 陷阱三（混淆無形效益與無價值）：無形效益絕非「次要效益」，在策略資訊系統（SIS）決策中往往是勝出關鍵。

3. 應考版面配置：四個子題嚴格各列滿五點，以（1）至（5）清楚編號，版面工整對齊，以爭取閱卷委員給予滿分。

---

【答案】

一、開發成本（Development Costs）

• 說明： 開發成本是指資訊系統在專案啟動、分析、設計、程式開發、測試至正式上線驗收期間所發生的一切費用。此類成本具有「一次性（One-time）」與「資本支出（Capital Expenditure）」之特性，系統完成建置後即停止發生。
• 五個例子：

1. 軟硬體基礎架構採購費：建置初期採購伺服器主機、網路防火牆、儲存設備（SAN/NAS）及作業系統／資料庫核心授權等費用。
2. 專案開發團隊人力成本：系統分析師（SA）、系統設計師（SD）、程式設計師（PG）及專案經理（PM）在開發期間的薪資、外包專案款項或顧問諮詢費。

核心觀念

本題出自系統分析與設計（System Analysis and Design, SAD）中「系統設計階段」的系統獲取策略（System Acquisition Strategies），主要考核系統分析師在規劃系統實作藍圖時，如何依據組織情境評估可行方案。

現代軟體工程經典理論（以 Dennis, Wixom, & Roth 之系統分析架構為典範）將建置新系統的可行途徑歸納為三大基本策略：

1. 自行開發（Custom Development / In-House Development）：由組織內部的資訊團隊從無到有（From Scratch）撰寫程式碼並建立系統。
2. 購買套裝軟體（Packaged Software / Commercial Off-The-Shelf, COTS）：直接向軟體廠商購買已開發完成之現成軟體套件，並視需要進行參數配置（Configuration）或適度客製化。
3. 外包（Outsourcing）：將系統之全部或部分分析、設計與開發工作，委託外部專業系統整合商（SI）、軟體顧問公司或雲端服務供應商代為執行。

決策時必須衡量五大核心構面：企業需要（Business Need）、企業內部經驗（In-house Experience）、專案技能（Project Skills）、專案管理（Project Management）​以及時限（Time Frame）。

---

解題方法

本題為典型的五構面 $\times$ 三方案矩陣型比較申論題（滿分通常為 20 至 25 分）。解題關鍵在於切忌將三種方法以流水帳方式條列，而應採用「構面為綱、方法為目」的架構，逐一對照剖析。

解題切入步驟如下：

1. 橫向構面拆解：依題意指定之 5 個評估角度依序展開，每個角度均涵蓋 3 種方法的優點、缺點及選用時機。
2. 論述邏輯對稱：每一項評估均以「優點（Pros）」、「缺點（Cons）」、「選用時機（When to Choose）」三要素精準呈現，展現結構化作答思維。
3. 收斂彙總矩陣：最後於答案末端提供標準決策矩陣（Acquisition Strategy Matrix），使閱卷委員能在一秒內掌握作答核心精髓。

---

評估維度深度分析

本題雖為申論題而非客觀選擇題，但歷年國考在評閱本題時，對三種開發途徑的判斷準則有高度一致之標準觀念，分析如下：

1. 企業需要（Business Need）

• 自行開發：
• 優點：具備百分之百的規格彈性，能完全貼合企業專屬或創新的業務流程，最大化保護營業秘密與核心競爭優勢。
• 缺點：若該功能屬於通用型需求，自行從頭開發將形成「重複造輪子（Reinventing the wheel）」，造成研發資源浪費。
• 選用時機：企業需要具高度獨特性（Unique），或該系統為組織創造市場差異化優勢的核心競爭系統。
• 購買套裝軟體：
• 優點：軟體本身已內建業界成熟的最佳實務（Best Practices），可靠度與成熟度高。
• 缺點：難以全面滿足組織特殊客製需求；若強行修改套件可能衍生高昂成本，否則企業必須被迫推動業務流程再造（BPR）以順應軟體流程。
• 選用時機：企業需要屬於通用普遍型（Common）​功能（例如：標準會計總帳、人資差勤、薪資發放、通用庫存管理）。
• 外包：
• 優點：能將複雜且特殊的非本業需求轉由外部專家實現，快速引進外部先進之商業模組與解決方案。
• 缺點：外包商對企業特有的核心策略理解較淺，需求傳達易失真，且容易面臨智慧財產權與商業機密外洩風險。
• 選用時機：企業需要非組織核心業務（Not core to the business），或業務雖關鍵但組織策略定位為不自行保有開發團隊。

2. 企業內部的經驗（In-house Experience）

• 自行開發：
• 優點：充分利用內部既有的領域知識（Domain Knowledge）與技術經驗，知識完全留存於企業內部。
• 缺點：受限於組織內部既有技術視野，若內部人員缺乏類似系統實作經驗，容易陷入摸索試錯的盲區。
• 選用時機：內部團隊已具備充足之功能性業務經驗（Functional experience）​與技術實作經驗（Technical experience）。
• 購買套裝軟體：
• 優點：無須具備底層程式碼開發經驗，主要倚重業務專家進行規格評選與功能適配性測試。
• 缺點：內部仍須具備一定的軟體測試與維運部署經驗，若缺乏基礎 IT 知識，難以有效配置系統參數。
• 選用時機：內部具備業務功能經驗以判斷軟體是否合用，但缺乏底層技術建置經驗。
• 外包：
• 優點：可迅速引進外部成熟的產業與技術經驗，迅速填補組織內部的技術空白。
• 缺點：專案完成後，寶貴的開發與系統架構經驗歸廠商所有，內部無法形成組織記憶，長期易產生技術依賴。
• 選用時機：內部完全缺乏相關功能與技術經驗（In-house experience does not exist），且無意自行摸索建立。

3. 專案技能（Project Skills）

• 自行開發：
• 優點：可透過實戰歷練培訓並深耕內部工程師的系統架構、編碼及測試等關鍵技能。
• 缺點：前期人員培訓的時間與財務成本極高，技術學習曲線陡峭；一旦關鍵人員離職，技能斷層風險大。
• 選用時機：組織具備明確的長期策略，強烈希望建立與深化內部技術技能（Desire to build in-house skills）。
• 購買套裝軟體：
• 優點：組織內部不需精通軟體架構與進階程式設計技巧，大幅降低專案團隊的技能門檻。
• 缺點：團隊轉而需要具備商業套裝軟體整合、API 串接、資料轉換及供應商談判等非開發型技能。
• 選用時機：技術技能並非組織欲長期深耕的核心能力，對技能的要求不具關鍵性（Skills are not critical）。
• 外包：
• 優點：完全繞過內部技能不足的障礙，直接調用市場上最先進、稀缺之專業技能。
• 缺點：內部團隊無任何實戰技能提升機會；若內部成員完全不具備驗收能力，將無法有效審查產出品質。
• 選用時機：屬於策略性決定（Strategic decision），組織認定此類技能不值得內部培育或市場人才過於稀有。

4. 專案管理（Project Management）

• 自行開發：
• 優點：專案控管權完全在組織內部，需求變更與進度溝通摩擦阻力小，進度透明度高。
• 缺點：專案管理難度極高，需涵蓋從需求分析到部署的完整生命週期（SDLC），專案經理承擔系統失敗之全責。
• 選用時機：專案擁有高素質之專案經理（Highly skilled PM），且組織具備成熟驗證過的開發方法論（Proven methodology）。
• 購買套裝軟體：
• 優點：管理範疇縮小為軟體安裝、客製化幅度控管、使用者驗收與教育訓練，時程較好掌握。
• 缺點：專案經理必須面臨大量的使用者變革管理（Change Management），抗拒心理與組織協調成本高。
• 選用時機：專案經理長於跨部門組織協調、使用者變更管理，並具備督導廠商導入之溝通能力。
• 外包：
• 優點：免除微觀的日常工程排程與編碼追蹤，管理職責聚焦於宏觀交付成果。
• 缺點：專案管理轉化為「合約管理」與「外部供應商監控」，若合約規範與驗收標準不清，易陷入進度失控或法律糾紛。
• 選用時機：專案擁有具備足夠職權層級之經理人，長於供應商管理、合約審查與服務水準協定（SLA）管控。

5. 時限（Time Frame）

• 自行開發：
• 優點：時程交付節奏完全由內部排程掌控，可依組織輕重緩急靈活調整階段性產出。
• 缺點：在三者之中時程通常最長，且若前期需求分析不清，常因「範疇蔓延（Scope Creep）」導致嚴重延宕。
• 選用時機：專案時限充裕且時程具備高彈性（Flexible time frame），無急迫上線壓力。
• 購買套裝軟體：
• 優點：軟體成品已經完工，只要進行基礎安裝與設定即可快速投產，在低客製化前提下上線速度最快。
• 缺點：若企業要求過度客製化修改，時程常因反覆除錯而急速膨脹，甚至超越自行開發。
• 選用時機：專案面臨極為迫切之法規遵循或營運時限，要求在極短時間內完成上線（Short time frame）。
• 外包：
• 優點：外包商能調動大量工程人力實施平行作業，若合約約定得宜，常能在短時間內滿足交付。
• 缺點：專案初期需經歷招標規範（RFP）研擬、評選、議價、簽約等漫長行政程序，前期耗時甚長。
• 選用時機：時限短或具彈性皆可（Short or flexible），取決於招標採購期與廠商既有模組庫的成熟程度。

---

解題技巧與常見陷阱

核心觀念

本題評量物件導向分析與設計（OOAD）中結構模型（Structural Models）的跨視圖一致性驗證（Cross-View Consistency Verification / Balancing）。

在系統分析與設計中，結構塑模是從「非正式概念」逐步精化為「正式規格與實例驗證」的過程：

1. CRC 卡（Class-Responsibility-Collaborator Card）：屬於概念層次（Conceptual Level）​的非正式文字模型，以責任導向設計（RDD, Responsibility-Driven Design）為基礎，記錄類別名稱、類別職責（Knowing 與 Doing）及協同合作者（Collaborators）。
2. 類別圖（Class Diagram）：屬於型態層次（Type-Level / Schema Level）​的正式靜態模型，定義系統中的類別（Class）、屬性（Attributes）、操作（Operations）及其間的靜態關係（關聯 Association、一般化 Generalization、聚合 Aggregation、組合 Composition、相依 Dependency）與多重性（Multiplicity）。
3. 物件圖（Object Diagram）：屬於實例層次（Instance-Level / Snapshot Level）​的具體模型，展現系統在特定時間點下，物件實例（Objects）、屬性值（Attribute Values）以及物件間連結（Links）的具體狀態，常用於驗證類別圖結構的正確性與邊界條件。

三者之間的一致性查核，在軟體工程中稱為水平一致性驗證（Horizontal Consistency Verification），包含語法一致性（Syntactic Consistency）（符號與名稱對應）與語意一致性（Semantic Consistency）（行為與約束條件不衝突）。

---

解題方法

要完整解答「如何查核驗證這三種表示法的一致」，標準切入架構為​「兩兩互查矩陣（Pairwise Check）」結合「情境走查與追溯（Scenario Walkthrough & Traceability）」，層層推導如下：

一、 查核維度一：CRC 卡 vs. 類別圖（概念模型 $\leftrightarrow$ 規格模型）

1. 類別實體對應（Class Mapping）：

• 每一張 CRC 卡必須在類別圖中找到唯一且名稱完全對應的類別（Class），反之亦然。若類別圖中有 CRC 卡未載明的類別，需確認是否為設計階段引進的介面（Interface）或控制類別（Control Class），否則即屬不一致。

2. 職責與成員對應（Responsibilities to Attributes & Operations）：

• 知道責任（Knowing Responsibilities）：CRC 卡上記載「類別應記住/知道的資訊」，必須映射為類別圖中該類別的屬性（Attributes）​或指向其他類別的關聯導航端點（Navigable Association Ends）。
• 行動責任（Doing Responsibilities）：CRC 卡上記載「類別應執行的動作」，必須映射為類別圖中該類別的操作/方法（Operations/Methods），且操作的存取權限（Visibility）通常應為公開（$+$）。

3. 合作者與關係對應（Collaborators to Relationships）：

• CRC 卡上列出的協同合作者（Collaborators），在類別圖中這兩個類別之間必須存在靜態關係（關聯、聚合、組合或相依）。若有合作者但在類別圖中無任何路徑相連，即代表模型不一致。

二、 類別圖 vs. 物件圖（型態模型 $\leftrightarrow$ 實例模型）

1. 實例分類合規性（Instantiation Conformity）：

• 物件圖中的每一個物件符號（語法標註為 objectName : ClassName 或 : ClassName），其對應的 ClassName 必須完全存在於類別圖中，不得出現未定義類別的物件。

2. 屬性與資料型態一致性（Attribute-Value Consistency）：

• 物件圖中物件所賦予的屬性名稱，必須精確屬於該類別在類別圖中所宣告的屬性清單。
• 物件圖中所賦予的具體值（Values），必須符合類別圖定義的資料型態（Data Type）與定義域約束（Domain / Invariant Constraints）。

3. 連結與關聯對應（Links to Associations）：

• 物件圖中兩物件之間的實體連線為「連結（Link）」，其必須是類別圖中對應兩類別間「關聯（Association）」的合法實例。類別圖中若無關聯，物件圖中絕對不可出現連結。

4. 多重性約束驗證（Multiplicity Constraints Verification）：

• 類別圖上定義的關聯多重性（例如 $1..*$、$0..1$），在物件圖的單一快照中，連至特定物件的 Link 數量必須完全落在該多重性區間內，不可違反上下限。

三、 CRC 卡 vs. 物件圖（概念模型 $\leftrightarrow$ 實例模型）

1. 角色實例化映射（Role-to-Instance Mapping）：

• CRC 卡走查過程中扮演角色的參與者，必須能映射至物件圖中參與特定情境的特定物件實例。

2. 合作路徑與連結驗證（Collaborative Paths Validation）：