108 調查局特考三等 資訊科學組 系統分析與設計 考古題詳解

核心觀念

本題考查系統取得策略的評估：依組織需求、資源與風險，選擇自行開發、採用套裝軟體、委外開發，或採取混合方案。重點不是預設某一種方式最好，而是先確認需求，再以一致的評估標準比較各方案。

三種方式的基本差異如下：

解題方法

採用「需求分析 → 可行性分析 → 方案比較 → 風險與治理安排 → 分階段決策」的程序，避免只以建置價格或交付速度作為選擇依據。

一、確認系統需求與策略重要性

先釐清系統要解決的問題，整理功能需求與非功能需求，例如：

• 業務流程、使用者角色、資料來源與輸出
• 資訊安全、個人資料保護、權限控管與稽核需求
• 效能、可用性、擴充性、維護性及法規遵循
• 與既有系統、資料庫及基礎設施的整合需求
• 預定上線時間、預算上限及預期使用年限

並判斷系統是否涉及組織的核心能力。若系統功能具有高度差異化，且攸關長期競爭力或關鍵業務，應特別重視需求掌握、技術知識與維護能力是否留在組織內。

二、評估各方案的可行性

依序評估以下面向：

1. 技術可行性：組織是否具備必要技術、設備、整合能力及維運能力？
2. 經濟可行性：建置與整體生命週期成本是否合理？預期效益是否足以支持投資？
3. 作業可行性：系統是否能配合實際流程？使用者是否接受？導入後是否需要調整組織作業？
4. 時程可行性：能否在業務期限內完成建置、測試、訓練與上線？
5. 法規與安全可行性：資料、資安、稽核、智慧財產權及契約安排是否符合要求？

成本應以總持有成本比較，而非只比較初始採購或開發費用。總持有成本可納入需求分析、建置或授權、客製、資料移轉、系統整合、教育訓練、維護、升級、資安管理及退場移轉等支出。

三、建立一致的比較標準

可採加權評分法，把重要因素列為準則，設定權重與各方案分數。常見準則包括：

• 功能符合度與客製彈性
• 初始成本與總持有成本
• 導入時程
• 系統品質、安全性與可靠性
• 與既有系統的整合難度
• 內部人力及技術能力
• 後續維護、升級及擴充能力
• 對廠商的依賴程度
• 智慧財產權、原始碼與資料掌控
• 導入失敗及營運中斷風險

核心觀念

本題考查專案管理中的成員激勵與衝突預防。專案經理須讓成員理解專案目標、願意投入工作，並透過公平的管理方式維持合作。激勵不能只靠獎金或命令，也要兼顧成員的需求、工作環境、成就感與團隊關係。

可運用下列管理觀念：

• 目標設定：目標應明確、具體、可衡量，並讓成員理解各自的責任與貢獻。
• 需求與激勵因素：薪資、工作保障等可改善不滿；成就感、責任、肯定與成長機會則有助於提高工作投入。
• 公平原則：工作分配、績效評估與獎勵標準須公開且一致，避免成員因感到不公平而降低合作意願。
• 衝突管理：衝突不一定有害；若能及早辨識並聚焦於問題與工作目標，能協助團隊釐清需求、改善方案。

解題方法

可依題目三個問句分成三部分作答：先說明如何激勵成員，再列出應避免的激勵方式，最後提出預防衝突的管理策略。答題時應將做法與專案目標連結，並兼顧個人需求、團隊合作及公平性。

一、激勵成員達成專案目標

1. 讓目標清楚且有意義 說明專案的目的、預期成果、時程與品質要求，使成員了解自己的工作如何影響整體成果。將大型目標拆成可追蹤的階段性成果，讓進度與貢獻容易看見。

2. 讓成員參與規劃與決策 邀請成員參與工作分解、時程安排與風險討論，聽取實務意見。成員參與目標形成後，通常更能認同計畫，也較願意承擔責任。

3. 依能力與興趣分派工作 了解成員的專長、經驗與發展需求，安排適當任務，並提供必要的授權與資源。授權應配合責任，避免只要求成果，卻不給決策空間或工作工具。

4. 提供及時、具體的回饋與肯定 定期檢視進度，針對具體貢獻給予肯定；發現偏差時，及早提供協助與改善方向。公開肯定可增強成就感，個別指正則應聚焦工作表現與可行改善方式。

5. 建立公平的獎勵與評估制度 事先說明績效標準，使獎勵與可衡量的成果、合作表現相連結。獎勵可包含適當的金錢報酬，也可包含表揚、訓練機會、擴大責任或職涯發展機會。

6. 營造支持性的團隊環境 提供所需資訊、設備、訓練與主管支援，鼓勵成員交流與互助。合理安排工作量，處理阻礙專案進度的問題，避免成員長期處於無法完成工作的狀態。

二、應避免的激勵方式

• 只靠金錢或短期獎金：金錢可作為激勵的一部分，但若只重視短期數量指標，容易犧牲品質、合作與長期成果。
• 設定不合理的目標或期限：目標明顯超出人力、資源或時程條件，會使成員認為努力也無法成功，進而失去投入意願。

核心觀念

本題考查三種反覆式開發方式的核心驅動力、主要產出與開發循環，以及它們在軟體開發不同階段如何搭配使用。三者分別以使用者目標、功能清單、測試案例作為迭代工作的主要依據。

• 使用案例驅動開發（Use Case-Driven Development）：以使用案例描述使用者與系統的互動及欲達成的目標，據此分析需求、設計系統、實作並驗證。迭代通常圍繞一個或一組使用案例進行，讓系統逐步交付可供使用者完成任務的功能。
• 功能驅動開發（Feature-Driven Development, FDD）：以可由使用者辨識、具有商業價值的「功能」（feature）作為開發單位。典型流程包含建立整體模型、建立功能清單、依功能規劃、設計功能、實作功能；每次短迭代完成一批功能。
• 測試驅動開發（Test-Driven Development, TDD）：以測試作為程式實作的先行規格。常見循環為「先寫一個會失敗的測試、撰寫最少程式使測試通過、重構程式並維持測試通過」，亦即 Red–Green–Refactor。TDD 著重程式層級的正確性與設計回饋，不等同於完整的系統測試或驗收測試流程。

解題方法

依序比較三者的迭代依據、工作粒度、主要參與者或產出、主要用途，再回答最後一問：良好軟體通常不是在整個生命週期只採用一種模型，而是在不同層次與階段搭配使用。

核心觀念

抽象類別（abstract class）用來表達一群物件的共同概念與共同介面。它不能直接建立物件，通常由子類別繼承，並提供共同屬性、已實作的方法，以及要求子類別實作的抽象方法。

抽象方法只有方法宣告，沒有方法本體。若子類別是具體類別，就必須實作繼承而來的抽象方法；若子類別仍未實作全部抽象方法，則該子類別也必須宣告為抽象類別。

因此，抽象類別與方法的關係可整理如下：

• 抽象類別可以同時包含已實作的方法與抽象方法。
• 抽象方法定義子類別必須遵守的行為介面。
• 子類別繼承抽象類別，並實作其抽象方法，以提供符合自身特性的行為。
• 子類別也可以覆寫父類別已實作的方法，改變或延伸其行為。

解題方法

本題是抽象類別觀念與 UML 類別圖、程式碼對照題。作答時應選擇一個具有「共同流程，但細節因子類別而異」的例子，先找出共同行為，再將變動部分設為抽象方法。

以下以「形狀」為例：所有形狀都可計算面積，但不同形狀的面積公式不同。因此，Shape 定義抽象方法 area；Circle 與 Rectangle 分別實作自己的計算方式。

類別圖

 <<abstract>>
 Shape
 +----------------+
 | + area: double |
 +----------------+
 △ △
 | |
 ┌────────┘ └────────┐
 | |
 Circle Rectangle
 +----------------+ +----------------------+
 | - radius: double| | - width: double |
 | + area: double| | - height: double |
 +----------------+ | + area: double |
 +----------------------+

UML 中，空心三角箭頭指向泛化關係的父類別；此例表示 Circle 與 Rectangle 繼承 Shape。抽象類別名稱可用斜體呈現，或標註 <<abstract>>；抽象方法名稱也可用斜體呈現。

相對應程式碼

以下以 Java 表示：