108 地方特考三等 資訊處理 系統分析與設計 考古題詳解

核心觀念

FAST（促進性應用規格技術）是一種以引導式團體會議進行需求導出的方法。它安排使用者、客戶代表與開發團隊共同討論，透過主持人引導參與者釐清問題、提出解決方向、協調不同意見，最後形成初步的軟體需求規格。

FAST 的重點是讓需求相關人員在同一場會議中共同確認需求，減少各自理解不同造成的溝通落差。它不是單純的腦力激盪，也不是由主持人替使用者決定需求；主持人負責維持討論秩序，需求內容仍由參與者共同提出與確認。

解題方法：掌握 FAST 的一般性規則

作答時可先說明 FAST 的目的與參與方式，再依會議的「場地、規則、議程、主持、記錄」整理一般性規則：

1. 選擇中立的會議地點 會議應安排在能讓各方專心討論的中立地點，避免特定部門或團體主導場域，影響其他人的發言。

2. 事先訂定準備與參與規則 明確說明會前應準備的資料、參與者的責任、發言方式及討論規範，使參與者了解如何投入會議。

3. 安排有結構但保留彈性的議程 議程要正式到足以涵蓋重要議題，也要保留彈性，讓參與者能提出新資訊、釐清疑問並充分交換意見。

4. 由主持人控制會議進行 主持人負責聚焦討論、掌握時間、平衡發言機會並協助協調歧見，使會議朝需求釐清與共識形成的方向進行。

核心觀念

本題考查敏捷式專案管理（Agile Project Management）​的定義、與傳統專案管理的差異，以及如何將敏捷方法落實於專案執行。此題不是計算題，也沒有特定法條；作答重點是掌握敏捷的核心精神，並把原則轉化成具體的團隊流程。

敏捷式專案管理是一種以短週期、漸進交付、持續回饋與快速因應變更為核心的專案管理方式。團隊把產品需求拆成小型、可完成且能驗收的工作項目，分批開發與交付，再依利害關係人的回饋調整後續工作。

敏捷強調以下價值：

• 個人與互動重於流程與工具。
• 可運作的產品重於鉅細靡遺的文件。
• 與客戶合作重於合約協商。
• 回應變更重於遵循原定計畫。

這些價值不表示流程、文件、合約或計畫沒有用，而是強調在專案管理中，應優先確保團隊協作、產品成果與對變化的回應能力。

解題方法

本題有三個作答任務：先定義敏捷，再比較傳統作法，最後說明實施步驟。作答時以「定義 → 比較 → 流程」組織內容，可完整回應題意。

一、敏捷式專案管理與傳統專案管理的差異

比較面向	傳統專案管理	敏捷式專案管理
規劃方式	前期進行較完整的範圍、時程與成本規劃，依計畫逐步執行	先確立方向與高優先需求，再以短週期規劃和調整
需求與範圍	偏重前期確認需求，變更通常須經正式評估與核准	接受需求隨回饋演進，持續排序並納入後續週期
交付方式	常在專案後期集中交付完整成果	每個迭代交付可檢視、可驗收的產品增量
團隊運作	工作依職能或階段分工，管理者較常負責指派與追蹤	跨職能團隊密切協作，團隊成員共同承擔交付責任
客戶參與	多在需求確認、階段審查或驗收時參與	持續參與需求釐清、迭代檢視與優先順序調整
控制與衡量	著重是否依基準計畫完成範圍、時程及成本	著重已完成且可驗收的成果、回饋與持續改善

傳統作法常以較固定的範圍、時程與成本基準進行控制；敏捷則透過短週期交付與持續排序，讓團隊能依實際成果和回饋調整工作。兩者都是專案管理方法，應依專案需求、風險與利害關係人特性選用。

二、敏捷式專案管理的施行方式

以下以常見的 Scrum 流程說明：

1. 建立產品願景與目標 由產品負責人（Product Owner）與利害關係人釐清產品要解決的問題、目標使用者及預期價值。

核心觀念

圈複雜度（Cyclomatic Complexity，又稱循環複雜度）是 McCabe 提出的程式控制流程複雜度度量，用來計算程式中線性獨立執行路徑的數量。它反映控制流程分支的多寡，常用於估計測試需求與維護難度；數值愈高，通常愈難完整測試與理解。

將程式表示為控制流程圖時，圈複雜度公式為：

$$V(G)=E-N+2P$$

其中：

• $E$：控制流程圖中的邊數。
• $N$：節點數。
• $P$：連通元件數；一般單一程式或函式為 $1$，因此公式簡化為 $V(G)=E-N+2$。

在單一連通程式中，也可使用下列等價算法：

$$V(G)=D+1$$

$D$ 是判斷節點數，例如 if、while、for 的條件判斷。每個判斷節點有兩條可能分支時，圈複雜度便比基礎路徑多 $1$。此處的圈複雜度不是程式碼的碼行數，也不直接表示執行時間或程式錯誤數量。

解題方法與計算示例

以下程式碼少於 50 行。程式有一個 if 判斷及一個 while 迴圈，可藉由判斷節點法及控制流程圖公式計算圈複雜度。

function sumPositive(values):
 total = 0
 i = 0

 while i < length(values):
 if values[i] > 0:
 total = total + values[i]
 i = i + 1

 return total

方法一：判斷節點法

1. 找出判斷節點：while i < length(values) 與 if values[i] > 0，共 $D=2$ 個。
2. 套用公式：

$$V(G)=D+1=2+1=3$$

因此，此函式的圈複雜度為 3，也就是有三條線性獨立路徑。

方法二：控制流程圖公式驗算

將控制流程圖節點列為：

1. 進入函式。
2. 初始化 total、i。
3. 判斷 while 條件。
4. 判斷 if 條件。
5. 執行加總。
6. 更新 i。
7. 回傳結果。
8. 結束。

因此 $N=8$。控制流程邊為：

1. 進入初始化。
2. 初始化至 while 判斷。
3. while 條件為真，進入 if 判斷。
4. while 條件為假，離開迴圈至回傳。
5. if 條件為真，進入加總。
6. if 條件為假，跳過加總。
7. 加總後進入更新 i。

核心觀念

大爆炸測試是一種整合測試策略：先分別完成各個模組，再將多個模組一次整合成完整系統，最後進行測試。測試時通常會確認模組間的介面、資料交換及整體功能是否符合需求。

「大爆炸」指的是整合方式：大量模組在同一階段接合，而不是逐一或分批整合。這種策略通常不依賴大量測試樁（stub）或測試驅動程式（driver），但實際上仍可能需要輔助工具。

解題方法

作答時先指出它是「一次整合多個模組」的整合測試策略，再分別從測試準備、問題定位、整合風險與執行彈性分析優缺點。

優點

1. 測試規劃較簡單：不必為每個整合階段安排逐步的測試順序，管理與排程較直接。
2. 通常較少需要測試樁與驅動程式：若各模組已完成，可直接整合後執行測試。
3. 適合規模較小、模組相依關係單純的系統：模組數量少且介面明確時，一次整合的成本可能較低。
4. 能直接觀察完整系統的整體行為：可在接近實際運作的組合下檢查端對端功能。

缺點

1. 問題定位困難：若整合後發現錯誤，缺陷可能來自任一模組，或模組間介面、資料格式及呼叫順序；不容易判斷問題所在。
2. 整合風險集中在後期：模組各自完成後才一起整合，介面不相容等問題可能很晚才暴露，增加修正成本。
3. 測試依賴所有相關模組都已完成：單一模組延遲或尚未穩定，就可能拖延整體測試。
4. 不利於早期發現缺陷：無法像增量整合那樣，在每次加入少數模組後立即驗證，故障回饋較晚。
5. 模組多、相依複雜時不易管理：錯誤來源與交互作用增加，整體測試可能需要較多時間才能查明問題。

解題技巧

快速辨識口訣是：「全部完成、一次整合；容易開始、難以除錯；風險後移。」​作答時不要只寫「簡單」或「困難」，應交代簡單之處在測試規劃與整合步驟，困難之處在缺陷定位及問題延後發現。

---

（二）操作設定檔或作業輪廓（Operational Profile）

核心觀念

操作設定檔是描述系統在實際使用情境中，各類操作或使用者行為發生頻率或機率分布的模型。它呈現系統「實際上會怎麼被使用」，例如不同功能被呼叫的比例、輸入資料型態的比例，或不同交易情境的發生頻率。