各類開發模式

SDLC

使用者可以清楚表達需求，開發階段均要清楚系統範圍，要有設計規畫文件、每個階段要進行驗證後，才可進入下階。

漸增

在瀑布模式中，一次要考量所有需求，而且在一個週期內就完成系統開發，執行上會有些難度，所以漸增模式就把需求切割成子系統，各別使用 SDLC 週期進行開發。由於每個週期都有使用者參與，所以可以盡早發現問題。
適用：需求明確，預算分期編列，組織需要時間熟悉新科技。

雛型

瀑布與漸增模式的運作基礎，是在需求能明確表達的前提下。但此與實際狀況不合，通常「使用者無法清楚表達需求」、「系統分析師經不夠，無法即時想出恰當方案」。針對這樣的狀況，只能針對需求較明確的部份，先行開發出一個系統雛型，再以此為基礎，作為溝通工具，釐清與反覆確認使用者需求。

特點：

1. 使用者高度參與，而且任何時間都可變更需求。
2. 適用在高風險、高變動性的專案上。
3. 快速見到系統雛型，失敗成本低。
4. 不適用在大型、複雜專案上。

分類：

1. 演進式：從需求清楚的部份進行開發，完成初版後，下次再以此為演進依據，加上使用者的回饋，反覆修改。每次演進都會一併考量新、舊需求。適用在系統開發初期，需求不明確時。

2. 設計式：用後即丟，用來確認需求規格，使用快速而粗糙的方式建立雛型，促使用戶決定需求項目。適用在高風險、高困難度之專案上。因為用後即丟，表示未來必需拋棄該架構，所以成本相對高。

螺旋

強調各開發週期的風險評估，
(1)找出目標限制 (2)評估方案風險 (3)由風險決定下一步

同步

把一個版本的系統分成多個「功能組」平行分派給多個團隊，進行開發。當一個版本的系統開發完成，交由獨立團隊進行測試，此時開發團隊可以進行下一版本的開發。目的在於縮短開發時程。主要精神有三：

1. 多團隊開發，多個工作平行進行，這種多組人同時工作的方式稱為活動同步
2. 資訊同步，各組間可以相互交流共享(向前/後傳遞)
3. 整合性的管理系統，因為使用同步模式，人力規模較傳統來得複雜。

RUP

使用反覆(Iterative)與漸增(Incremental)的方式進行軟體開發。反覆指的是，使用相同的步驟進行系統開發；漸增指的是，每次都在軟體上加入新功能、模組。每一次的反覆都會生成一個可運作版本，並可在每個週期中評估相關風險。

動態階段：
1. 初始：瞭解專案風險，建立系統需求與範圍，取得人員認同 (完成專案生命週期目標)
2. 詳述：進行系統的設計、編碼、測試。並以實際的程式架構，來探討技術風險。建立系統基本結構 (完成生命週期結構)
3. 建構：建立一個初步可運行版本(可演化)系統α版 (最後完成一個有完整功能的系統β版)
4. 轉移：建立最終軟體交給顧客 (完成產品出版)，包括備份、培訓、支援。

靜態階段：
1. 企業塑模：導出系統需求以支援組織目標，產出企業模型。
2. 需求：定義軟體細部需求
3. 分析設計：將需求轉成系統實作的規格
4. 實作
5. 測試
6. 配置
7. 組態管理、專案管理、環境 - 此屬管理支援

模式驅動結構 MDA (Model Driven Architecture)

(1) 每個過程都會產出「模式」
(2) 模式的表達是用「正規模式」讓電腦可以理解
(3) 分析階段產出 PIM(高階抽象模式，與開發技術獨立，不涉及運作平台)
(4) 設計階段產出 PSM(與特定平台相關)
(5) 三個核心是：PIM + PSM + Code

敏捷開發 (Agile)

適用在：非關鍵專案、公司文化適合、地域近、有經驗團隊
(1) 個體的互動勝於流程：重視團隊工作，SA、程式師、客戶一起工作
(2) 可運作軟體勝於文件：用軟體來衡量開發進度
(3) 懂得變化，而非遵守計畫。

極限編程 (Extreme Programming, XP)

(1) 編碼，程式師碰到開發問題時，可用所寫的程式與人討論想法
(2) 測試，系統開發時間，使用測試來確認功能可否運作。
(3) 傾聽，開發人員要傾聽使用者需求
(4) 設計，系統開發需要經由設計來釐清系統範圍