108 外交特考四等 外交行政人員資訊組 系統分析及設計與資料庫應用概要 考古題詳解

核心觀念

扇入（Fan-in）​是指一個模組被多少個其他模組直接呼叫，也可理解為該模組有多少個直接上游呼叫者。扇入高，表示模組可能被多處重複使用，具有較高的共用性；但若模組承擔過多不同責任，也會增加維護與測試負擔。

扇出（Fan-out）​是指一個模組直接呼叫多少個其他模組，也就是它有多少個直接下游模組。扇出高，表示該模組需要協調較多元件，控制流程與依賴關係通常較複雜。

例如，若模組 A 呼叫 B、C、D，A 的扇出為 3；若 B 同時被 A、E 呼叫，B 的扇入為 2。此處計算的是直接呼叫關係，不包含間接呼叫。

解題方法與架構原則

本題分成兩部分作答：先定義扇入、扇出，再說明它們在良好架構中的規劃原則。扇入與扇出是架構分析的指標，不能單獨以「越高越好」或「越低越好」判斷。

1. 扇入適度提高，鼓勵合理重用。 共通且責任明確的服務，如輸入驗證、日誌紀錄或格式轉換，可由多個模組呼叫，形成較高扇入。這有助於減少重複程式碼。但若一個模組被大量地方依賴，修改它可能波及許多呼叫者，因此仍要維持介面穩定、責任單一，避免形成難以變更的共同瓶頸。

核心觀念

本題考查專案時程管理中的排程方向與資源配置。專案經理須先掌握各項工作的工期、先後依存關係及資源需求，再據此安排時程。正向排程與逆向排程用來推算工作可行的開始、完成時間；資源平準則著重調整工作時程，使資源需求較符合可用資源。

解題方法

以專案網路圖中的工作依存關係為基礎，分別說明排程的推算方向，再說明資源需求超出可用量時，如何透過調整工作安排來處理。

正向排程（Forward Scheduling）

從專案的起始日或起始事件開始，依工作依存關係由前往後推算各工作的最早開始時間（Early Start, ES）與最早完成時間（Early Finish, EF）。

若工作工期為 $d$，則：

後續工作須等所有前置工作完成後才能開始；若有多個前置工作，後續工作的最早開始時間為其前置工作最早完成時間的最大值。正向排程可求得專案最早完成時間。

逆向排程（Backward Scheduling）

從指定的專案完成日或最後一項工作的完成時間開始，依工作依存關係由後往前推算各工作的最晚完成時間（Late Finish, LF）與最晚開始時間（Late Start, LS）。

若工作工期為 $d$，則：

核心觀念

本題考查 ERD 的基本建模：辨識實體與屬性、設定主鍵、處理多值屬性，以及依題意標示實體間的基數與參與限制。題目沒有要求指定 ERD 表示法，以下採用 Crow’s Foot（烏鴉腳）概念說明。

• 主鍵：能唯一識別一筆實體資料的屬性。
• 複合主鍵：由多個屬性共同識別資料。
• 多值屬性：一筆實體資料可對應多個屬性值；在 ERD 可畫成雙橢圓，在關聯式資料庫實作時通常另建資料表。
• 基數：表示一端的每筆資料可與另一端多少筆資料相關。
• 參與限制：表示關聯是否為必須；例如「一個職缺必對應於一個職位」代表職缺對職位是必須且恰為一個。

解題方法

先依題幹列出四個實體，再逐一標記識別屬性與多值屬性，最後從句子中的「一個」「可能」「必須」判斷關聯基數與參與限制。

1. 部門

部門編號唯一，因此為主鍵；部門地址可有多個，因此是多值屬性。

• 實體：部門
• 主鍵：部門編號
• 一般屬性：部門名稱
• 多值屬性：部門地址

2. 職位

職位沒有單一唯一屬性，但題目明確指出「同一部門的各個職位的職位名稱必不同」。因此，職位名稱只能在部門範圍內識別職位，職位的主鍵採用 （部門編號、職位名稱）。

• 實體：職位
• 複合主鍵：部門編號、職位名稱
• 一般屬性：職責敘述

職位名稱不是全公司唯一；不可只把職位名稱當成主鍵。

3. 職缺

職缺編號唯一，作為主鍵；其餘為一般屬性。

• 實體：職缺
• 主鍵：職缺編號
• 一般屬性：職缺條件、職缺人數、出缺日期

每個職缺必對應一個職位；一個職位可分成數個職缺。因此，職位與職缺是 一對多，且每個職缺必須參與此關聯。

4. 應徵者

核心觀念

本題測驗資料庫系統的基本觀念：資料庫如何隱藏儲存細節、描述資料結構、提供資料存取，以及維持程式與資料結構之間的彈性。五個名詞彼此相關，但所指層次不同：

• 資料抽象化著重隱藏複雜細節。
• 資料模型用來描述資料、資料間的關係與限制。
• 資料獨立著重資料結構變動時，降低對其他層次的影響。
• 資料操作語言用來查詢與異動資料。
• 資料字典保存資料庫中各項定義與描述資訊。

解題方法

依序從「如何看見資料庫」、「如何描述資料」、「如何降低變更影響」、「如何操作資料」及「如何查閱定義」說明，即可清楚區分五個名詞。作答時應掌握各名詞的目的與典型例子，避免把它們都簡化為「管理資料」。

（1）資料抽象化（Data Abstraction）

資料抽象化是指資料庫系統隱藏資料儲存與實作的複雜細節，讓使用者依其需求看到適當的資料內容。傳統資料庫教材常將其分成三個層次：

1. 實體層（Physical Level）：說明資料實際如何儲存，例如檔案配置、索引及存取路徑。
2. 邏輯層（Logical Level）：說明資料庫包含哪些資料、資料間的關係，以及相關限制。
3. 視觀層（View Level）：呈現特定使用者或應用程式所需的資料視圖，隱藏不相關或不宜公開的部分。

例如，人事系統的使用者只需看到員工姓名與部門，不必了解資料實際存放在哪個磁碟區塊。這種隱藏底層細節、提供較易理解的資料呈現方式，就是資料抽象化。

（2）資料模型（Data Model）

資料模型是一組用來描述資料庫的概念與工具，通常包含：

• 資料結構：資料如何組織，例如資料表、欄位及資料類型。
• 資料間的關係：例如兩個資料表如何透過鍵值關聯。
• 資料限制：例如主鍵不可重複、外鍵須參照有效資料。

常見的資料模型有關聯式模型、階層式模型、網路模型及實體關係模型（ER Model）。例如，關聯式模型以資料表、資料列及欄位呈現資料，並以主鍵與外鍵表達資料間的關係。

資料模型回答的是「資料庫有哪些資料、彼此如何關聯，以及必須符合什麼規則」，是資料庫設計及溝通的基礎。

（3）資料獨立（Data Independence）

資料獨立是指資料庫某一層次的結構或描述發生變更時，盡量不影響較高層次的資料視圖或應用程式。主要分為兩種：

1. 實體資料獨立（Physical Data Independence）：改變實體儲存方式，而不必修改邏輯結構或應用程式。例如新增索引、調整檔案配置。

核心觀念

資料庫語言可依用途區分。資料定義語言（DDL，Data Definition Language）用來建立或修改資料庫結構，例如資料表、欄位與索引；常見指令有 CREATE、ALTER、DROP。資料操作語言（DML）則用來查詢或異動資料，例如 SELECT、INSERT、UPDATE、DELETE。

解題方法

辨認各指令的作用：若指令改變的是資料庫的結構，屬於 DDL；若查詢或異動的是資料內容，則屬於 DML。ALTER 用於變更既有資料庫物件的定義，因此屬於 DDL。

選項分析

核心觀念

本題考查 SQL 的內建函數，特別是常見的彙總函數。彙總函數可對多筆資料計算統計結果，常用於 SELECT 子句，也可搭配 GROUP BY 依群組計算。

解題方法

逐一辨認選項是否為 SQL 常見內建函數：

• AVG：計算數值欄位的平均值。
• COUNT：計算資料筆數或非空值個數。
• MAX：取得欄位中的最大值。
• BET：不是 SQL 內建函數名稱。

因此，沒有提供內建函數的是 (B) BET。

選項分析

• (A) AVG：錯誤選項。 AVG 是彙總函數，用來計算數值的平均值。
• **(B) BET：正確選項。

核心觀念

本題考查大數據分析常見的分析方法，以及「數值分析」與「資料分析」在考試語境中的區別。大數據分析常用來找出資料中的關聯、分類或群集、趨勢與時間變化，常見方法包括關聯規則、分類／分群與時間序列分析。

解題方法

先辨認各選項是否屬於常見的大數據分析方法：

• 關聯規則用來找出資料項目間經常共同出現的關係。
• 分類／分群用來辨識資料類別，或依資料相似性形成群集。
• 時間序列分析用來觀察資料隨時間變化的趨勢與模式。
• 數值分析則是以數值方法處理數學問題的領域，並非此處常列舉的大數據分析方法。

因此，依題目所採用的分類方式，較不屬於大數據分析常見方法的是「數值分析」。

選項分析

(A) 數值分析（Numerical Analysis）—正確答案

數值分析主要研究如何使用數值計算方法近似求解數學問題，例如數值積分、方程式求根與數值微分。它不是大數據分析常見的資料探勘方法分類，因此符合題目「比較不採用」的描述。

(B) 關聯規則（Association Rules）—錯誤

核心觀念

本題考資料庫管理者（Database Administrator，DBA）的主要職責。DBA負責管理資料庫的整體規劃與運作，例如決定資料庫的內容與結構、管理使用者權限、維護資料安全、備份資料，以及監控和調整資料庫效能。

資料的日常建檔、輸入與儲存，通常由使用者或負責資料處理的工作人員執行，並非 DBA 的主要職責。

解題方法

逐項區分「資料庫管理與維護」和「資料內容的日常處理」：

• 涉及資料庫規劃、權限、安全、備份或效能管理，屬於 DBA 的職責。
• 涉及日常資料建檔與輸入，通常屬於一般使用者或資料作業人員的工作。

因此，選出最不屬於 DBA 主要職責的選項。

選項分析

核心觀念

本題考查資料庫中的主鍵與外來鍵。

• 主鍵（Primary Key）：能唯一識別資料表中每筆紀錄的欄位或欄位組合，值須唯一且不可為空。
• 外來鍵（Foreign Key）：用來參照另一資料表的主鍵，或具有唯一性限制的候選鍵；外鍵值須能在被參照欄位中找到相符紀錄。
• 欄位是否適合作為鍵，可先依題目提供的資料檢查值是否重複、是否有找不到對應資料的情形。

解題方法

逐一檢查選項所述的欄位：

1. 對主鍵選項，檢查該欄位在表中是否有重複值。
2. 對外來鍵選項，檢查被參照欄位是否具唯一性，以及外鍵值是否都能在被參照表中找到。

選項分析

(A) C-Code 和 C-Country 都可以作為 Country 資料表的主鍵：正確。 依題目表格，C-Code 的國家代碼皆不重複；C-Country 的國名也皆不重複。因此依本題提供的紀錄，兩者都能唯一識別 Country 表中的各筆資料。

(B) Project-ID 和 Project-Title 都可以作為 Project 資料表的主鍵：正確。 Project 表中的 Project-ID 各不相同；Project-Title 的計畫名稱也各不相同。

核心觀念

本題考查資料分析與交易處理的用途差異，以及 OLAP 常見的多維度資料操作。

• OLTP（線上交易處理）​支援日常業務交易，例如訂票、轉帳及下單，重視大量交易能在短時間內完成，並維持資料正確性。
• OLAP（線上分析處理）​利用累積的歷史資料，從不同維度進行彙總與分析，協助了解趨勢及支援決策。
• 第三正規化（3NF）​是關聯式資料庫的正規化形式，主要用來降低資料冗餘與更新異常；它不是大數據分析的必要前置步驟，也不必然能加速分析。

解題方法

先辨認各選項描述的是 OLAP、OLTP 還是資料正規化，再檢查敘述是否把某種資料處理方式說成一律適用。

OLAP 的常見操作包括彙總（Roll-up）、向下鑽取（Drill-down）、切片與切塊（Slice and Dice）。OLTP 則著重快速處理多筆日常交易。若選項宣稱大數據分析「必先」將資料轉為 3NF，便與大數據分析可採用多種資料模型及處理架構的實務不符。

選項分析

(A) 正確。 OLAP 通常以歷史資料進行分析，藉由期間、地區、產品等維度觀察趨勢，進而掌握近期或目前的營運情況。

核心觀念

資料庫語言可依用途分為幾類：

• 資料控制語言（DCL）：管理使用者的權限，例如授予或撤銷資料庫存取權。
• 資料查詢語言（DQL）：查詢資料，例如 SELECT。
• 資料操作語言（DML）：新增、修改或刪除資料，例如 INSERT、UPDATE、DELETE。
• 資料定義語言（DDL）：建立或修改資料庫結構，例如 CREATE、ALTER、DROP。

本題要辨認各指令的用途，找出管理權限的 DCL 指令。

解題方法

逐一判斷選項操作的對象：若操作的是使用者權限，屬於 DCL；若查詢或變更資料內容，屬於 DQL 或 DML；若變更資料表等結構，則屬於 DDL。

選項分析

核心觀念

本題考查物件導向分析與設計中「類別（Class）」的基本概念。類別是對一群具有共同屬性與行為的物件所作的抽象描述。類別通常包含：

• 屬性（Attribute）：描述物件的狀態或特徵。
• 操作（Operation）：描述物件可以執行的行為。
• 名稱（Name）：用來識別類別。

子類別可以繼承父類別的屬性與操作，並可新增屬性或操作，也能透過覆寫等方式調整繼承而來的行為；因此，子類別並不會與父類別完全相同。

解題方法

逐一核對選項是否符合類別、屬性、操作與繼承的定義。前三項描述類別的基本組成或屬性用途；判斷重點在於選項是否把「繼承」誤解成子類別不能改變父類別的內容。

選項分析

核心觀念

本題考資料庫正規化中，第三正規化（3NF）要消除的遞移相依性。

若某關聯的主鍵為 $K$，非鍵屬性為 $A$、$B$，且存在：

則 $B$ 經由 $A$ 間接相依於主鍵 $K$，稱為遞移相依。第三正規化的基本要求，是非鍵屬性須直接依賴候選鍵，不應透過另一個非鍵屬性間接依賴主鍵。

解題方法

看到題幹「移除可遞移相依性」及「只由主鍵來識別非鍵屬性」，即可判斷是在問第三正規化。此處的「只由主鍵來識別非鍵屬性」是考試常見的簡化說法，重點是非鍵屬性不可經由其他非鍵屬性遞移相依於主鍵。

選項分析

核心觀念

本題考查 ER 圖中常見符號的意義。弱實體（weak entity）​無法只靠自身屬性唯一識別，必須依賴另一個實體型態才能存在或被識別；其圖示為雙矩形。弱實體通常透過識別關係（identifying relationship）連結至其擁有者實體，且會使用部分鍵搭配擁有者實體的鍵來識別。

解題方法

辨認題目指定的圖形符號，再對照 ER 圖慣例：雙矩形代表弱實體；雙菱形代表識別關係。題目問的是「雙矩形」，因此選擇描述依賴其他實體才能存在的弱實體形態。

選項分析

核心觀念

本題考資料庫中的交易（transaction）。交易是資料庫系統執行作業時的一個邏輯單元，包含為完成該作業所需的一組資料庫處理動作。交易通常以 COMMIT 確認並永久保存結果，或以 ROLLBACK 撤銷尚未確認的變更。

交易常以 ACID 四項特性說明：

• 原子性（Atomicity）：交易中的動作全部完成，或全部不生效。
• 一致性（Consistency）：交易執行前後，資料庫均符合設定的完整性規則。
• 隔離性（Isolation）：並行交易彼此隔離，避免不當干擾。
• 持久性（Durability）：交易確認後，其結果能持續保存。

解題方法

抓住題幹中的「作業的邏輯單元」與「所有處理動作的集合」兩個關鍵描述，即可對應到交易的定義。題目問的是一組資料庫動作所構成的整體單位；COMMIT 則是交易完成時確認結果的操作，並非這個邏輯單元本身。

核心觀念

本題考查資料庫的綱要（schema）。綱要是資料庫的整體結構描述，界定資料庫有哪些資料表、欄位、欄位型態與彼此關係等；可視為資料庫的結構藍圖。

解題方法

抓住題幹中的「代表模型結構的相關描述與定義」。在資料庫術語中，描述資料庫整體結構的是綱要（schema）；實際儲存的資料則是資料庫實例（instance）。因此，本題選擇綱要。

選項分析

• (A) 視界（view）：視界是由查詢定義的虛擬資料表，呈現資料庫中部分資料或特定觀點，不是資料庫整體結構的描述。

核心觀念

需求分析是需求工程的重要工作，目的在於了解系統應解決的問題、確認使用者與其他利害關係人的需要，並將需求整理成可溝通、可檢視及可供後續設計使用的成果。需求來源不只有直接操作系統的使用者，也可能包含管理者、外部系統、法規與其他受系統影響的對象。

解題方法

判斷各選項是否正確，可看它是否符合需求分析的兩個基本原則：需求須由相關來源共同確認，且需求成果應能清楚描述系統要提供的功能與限制。只要選項排除利害關係人參與，便與需求分析的實務相違。

選項分析

(A) 正確。 需求來源不只包括直接使用系統的人，也包括與系統交換資料或互相影響的相關系統。分析這些來源，有助於掌握介面、資料交換及相依性需求。

核心觀念

UML 圖可依描述角度區分為靜態觀點與動態觀點。靜態觀點呈現系統的結構與組成，例如類別、屬性、操作及類別間的關係；動態觀點則呈現系統行為如何隨時間、事件或流程變化。

解題方法

判斷圖示主要描述的是「系統由哪些結構組成」，還是「系統如何運作」。類別圖描繪類別及其關係，重點在系統結構，因此屬於靜態觀點；狀態機圖、順序圖與活動圖則用來描述行為或流程，屬於動態觀點。

選項分析

• (A) Class Diagram（類別圖）—正確。​呈現類別、屬性、操作，以及類別間的關聯、繼承等結構關係，描述系統的靜態結構。

核心觀念

本題考查軟體性能測試的目的與類型。壓力測試（Stress Testing）會逐步增加系統負載，觀察效能如何變化，直到系統無法維持可接受的服務水準，以找出系統的失效邊界及最大服務能力。

解題方法

抓住題幹中的兩個關鍵線索：「逐步增加系統負載」與「找出性能失效時的負載條件」。這描述的是讓系統承受超出一般預期的負載，測出其極限，因此選擇壓力測試。

選項分析

• (A) 壓力測試：正確。 透過逐步提高負載，觀察系統在高負載下的效能與失效情形，藉此確認系統承受能力的上限。
• **(B) 穩定性測試：錯誤。

核心觀念

本題考「資訊系統開發方法」的辨識，關鍵在於題幹所描述的開發環境：以物件導向為基礎、透過網路提供開發指引，並整合開發流程、技術、實作成果與文件等資源。這些特徵符合 Rational Unified Process（RUP，理性統一過程）。

RUP 是一套物件導向、迭代式的軟體開發流程架構，提供流程指引、範本與相關開發產出物，協助團隊依循一致的方法進行開發。

解題方法

抓住題幹中的兩組線索即可判斷：

1. 物件導向、網路化的開發框架：指向 RUP 所提供的流程與開發支援環境。
2. 整合物件定義、技術、實作及文件、模型、手冊、程式碼等產出物：說明它不只是單一開發階段或專案模型，而是涵蓋開發流程與相關資源的統一架構。

因此，應選擇 RUP。

選項分析

• (A) Rapid Prototyping（快速雛型法）錯誤。 快速雛型法著重迅速建立系統雛型，讓使用者試用並提供回饋，再據此調整需求或設計。它的核心是雛型與反覆修正，並非題幹所述的整合式開發框架。

核心觀念

本題考「模組內聚力」的分類。內聚力描述一個模組內各項功能彼此相關的程度；通常內聚力越高，模組的責任越明確、越容易維護。

邏輯內聚（Logical Cohesion）​是指模組包含數個性質或目的相近、屬於同一類型的操作，但實際執行哪一項操作，是由外部控制資訊（例如旗標或選擇參數）決定。題幹所說「同一種類」以及「由外在的模組或類別來控制呼叫」，正是這種特徵。

解題方法

先看兩個關鍵線索：

1. 模組內有多個操作，而且這些操作屬於同一種類。
2. 外部模組或類別負責控制要呼叫哪一個操作。

這表示模組是依「操作的類別」把多項功能集合在一起，再由外部選擇具體要執行的功能，因此判定為邏輯內聚。

選項分析

• (A) 資訊內聚：錯誤。 資訊內聚是指模組內的操作都針對同一份資料或同一個資料結構，各操作通常各自執行，且可能各自有不同的進入點。

核心觀念

本題考查白箱測試（White-box testing）​與黑箱測試（Black-box testing）​的差異。

白箱測試又稱結構測試，測試人員須了解程式的內部結構，例如程序、控制流程、演算法與程式碼，並據此設計測試案例。黑箱測試則不檢視程式內部，主要依規格或功能，檢查輸入與輸出是否符合預期。

解題方法

判斷選項時，先看描述的測試角度：

• 提到「內部結構、演算法、程式邏輯」：屬於白箱測試。
• 提到「使用者角度、輸入與輸出、系統功能」：屬於黑箱測試。

因此，描述測試人員必須了解待測程序內部資訊的選項，符合白箱測試定義。

選項分析

核心觀念

本題考查 UML 順序圖（Sequence Diagram）與類別圖（Class Diagram）的分工及相互對應。

• 類別圖描述系統的靜態結構，包括類別、屬性、操作，以及類別間的關係。
• 順序圖描述特定情境下，物件隨時間傳遞訊息的互動，包括訊息的先後、條件分支與重複等控制流程。

兩種圖需要彼此一致，但順序圖呈現的互動流程不必全部由類別圖中的條件直接決定。

解題方法

逐項檢查敘述是否混淆靜態結構與動態行為：物件、操作及物件間的互動，通常須能對應至類別圖的結構；訊息的執行順序與分支則屬於順序圖對情境流程的描述。據此可判斷，將順序圖的流程變化一概要求由類別圖條件規定的敘述不正確。

選項分析

(A) 正確。 順序圖中的物件是類別的實例，其所屬類別應在類別圖中定義，才能確認物件的型別及可用操作。

核心觀念

本題考「間接機制」（Indirection）設計原則。當兩個類別直接依賴彼此、耦合度過高時，可加入一個中間類別，讓原本的類別透過中間類別互動。如此能降低彼此的直接依賴；若介面或資料格式有所變動，也可由中間類別負責轉換，減少修改原有類別的需求。

解題方法

抓住題幹的兩個關鍵線索：「增加一個中間的類別」以及「降低原有類別的耦合」。這正是以中間層隔開直接依賴、轉移變動影響的間接機制，因此選擇（B）。

例如，訂單類別不直接依賴某一種付款系統，而是透過付款介面或轉接類別處理付款。更換付款系統時，主要調整中間層即可，降低訂單類別與付款系統的耦合。

選項分析

核心觀念

本題考查 AJAX 網頁登入流程中的非同步請求。JavaScript 建立 XMLHttpRequest 物件並呼叫 send 後，瀏覽器可在等待伺服器回應時繼續處理其他操作；伺服器回傳資料後，再由 callback 處理回應並更新頁面。

解題方法

依圖中的訊息順序判讀：

1. User 呼叫 JavaScript 的 Login。
2. JavaScript 建立 XMLHttpRequest，再呼叫 send。
3. 請求以 HTTP GET/POST 傳到 Server Processor。
4. 伺服器回傳 XML 文件後，JavaScript 執行 callback，接著呼叫 updatePage。

判斷關鍵在於 send 所代表的請求是非同步：等待伺服器回覆時，使用者仍可操作瀏覽器，不必停在原地等待。

選項分析

核心觀念

結構圖（Structure Chart）與 HIPO 圖都是系統設計階段用來描述模組的工具。它們著重呈現系統的階層式模組結構，以及模組間的呼叫與資料傳遞關係。

HIPO 是「階層式輸入、處理、輸出」（Hierarchical Input Process Output）的縮寫，包含階層圖與輸入、處理、輸出圖，藉此說明系統由哪些模組組成，以及各模組的功能。結構圖則以模組方框、連線與資料流等符號，呈現模組間的呼叫和資訊交換。

解題方法

先辨認這些工具描述的重點：它們回答「系統如何分解成模組、模組如何互動」，而非詳細說明單一模組內部的程序邏輯。逐項比對選項，找出超出結構圖與 HIPO 圖主要用途的項目。

選項分析

• (A) 表達系統的模組結構：正確用途。 結構圖以階層方式呈現模組分解與上下層關係；HIPO 的階層圖也用來表達系統的模組組成。

核心觀念

演化模型（Evolutionary Model）是透過反覆開發與修正，逐步形成完整系統的開發方式。開發人員先交付可運作的核心版本或原型，再依據使用者試用後的回饋，逐次擴充功能、改善效能，讓系統隨開發過程逐漸演進。

此模型適合需求尚未完全明確，或需要透過原型與使用者互動來釐清需求的情境。相較之下，若需求已能事先完整定義，較符合瀑布模型等依循既定需求逐階段開發的方式。

解題方法

抓住演化模型的關鍵：先交付可用版本，再依回饋逐步演進。據此判斷各選項是否符合原型試用、需求逐步明確、增量改善等特性；若選項主張需求必須事先完整定義，便與演化模型的典型適用情境不符。

選項分析

核心觀念

本題考查模組化設計的品質原則：高內聚、低耦合。

• 內聚力（cohesion）：衡量同一模組內各項工作彼此相關的程度。內聚力高，表示模組集中處理一項明確、相近的責任，功能較容易理解與維護。
• 耦合力（coupling）：衡量不同模組之間的依賴程度。耦合力低，表示模組間依賴少、介面清楚；修改一個模組時，較不容易連帶影響其他模組。

解題方法

題幹要讓系統發展「更為簡潔迅速」並「降低未來的維護成本」，關鍵在於讓每個模組的責任清楚集中，同時減少模組彼此牽連。因此應採取高內聚、低耦合的模組設計。

選項分析

核心觀念

敏捷軟體發展（Agile Software Development）重視在需求與環境變動時持續調整，並透過短週期、反覆交付與回饋，逐步建構系統。敏捷宣言的核心價值之一是「回應變化重於遵循計畫」；這不代表完全不做計畫，而是讓計畫能依新資訊調整。

敏捷開發通常採取漸增式、迭代式與演化式的方式：每個迭代都會產出可檢視的成果，並依回饋修正後續工作。

解題方法

判斷關鍵在於區分敏捷開發與瀑布式模型的流程：瀑布式模型通常依序完成需求、設計、建置、測試等階段；敏捷則以短迭代反覆進行分析、設計、建置與測試，並持續吸收回饋。因此，聲稱敏捷必須「完成一個階段後，再進入下一階段」，是把瀑布式的線性流程套用到敏捷上。

選項分析