# 什麼是 SDLC？軟體開發的 6 大必經之路

開發軟體就像「蓋房子」，不能直接拿起磚頭就開始砌牆。SDLC 是一套標準流程，確保軟體能高品質地完成，並且符合使用者的需求。

## 一、 SDLC 流程拆解：從想法到產品

軟體開發通常分為以下六個階段，我們可以用 **SA、SD、PG** 等職位代稱來快速記憶：

### 1. 需求分析與規劃 (System Analysis, SA)
- **白話文：** 搞清楚「要做什麼」。搞清楚「誰」要用「什麼」功能，以及業務的「邏輯」為何。
- **核心任務：** 收集客戶的想法，評估這個功能做不做得到？需要花多少錢？多久會做好？釐清功能邊界、梳理複雜的業務規則。
- **關鍵產出：** * **需求單：** 客戶最初始的想法。
- **隨意記錄/會議記錄：** 討論過程中的細節與共識。
- **SRS (需求規格說明書)：** 將模糊的想法變成具體的軟體功能清單。
- UML：
- **使用案例圖 (Use Case Diagram)：**
- **用途：** 畫出有哪些使用者（Actor）以及他們能操作的功能（Use Case）。
- **對 PG 的價值：** 讓開發者一眼看出系統的服務對象與功能範圍。
- **活動圖 (Activity Diagram)：**
* **用途：** 類似流程圖，描述業務的邏輯流向（例如：結帳時餘額不足要跳轉到哪一步）。
* **對 PG 的價值：** 這是寫 `if-else` 邏輯最精確的參考依據。

### 2. 系統設計 (System Design, SD)
- **白話文：** 畫出「設計圖」。決定「怎麼做」。將 SA 的規格轉化為程式結構與資料關聯。
- **核心任務：** 決定軟體的外觀（UI/UX）、資料庫怎麼存資料（設計資料庫結構）、定義程式類別、規劃 API 呼叫順序、系統整體的架構。
- **關鍵產出：** * **DDS (系統設計說明書)：** 給工程師看的施工藍圖。
- **資料庫關聯圖 (ER Diagram)**、**介面原型 (Wireframe)**。
- UML：
- **類別圖 (Class Diagram)：**
- **用途：** 定義物件的屬性、方法以及彼此間的關係（繼承、關聯）。
- **對 PG 的價值：** 最重要的一張圖。工程師可直接據此建立資料庫 Table 與程式中的類別架構。
- **循序圖 (Sequence Diagram)：**
* **用途：** 描述物件之間在時間軸上的互動（例如：前端 call API，後端如何查資料庫再回傳）。
* **對 PG 的價值：** 讓開發者知道程式執行的先後順序，避免邏輯斷層。
* **狀態圖 (State Machine Diagram)：**
* **用途：** 描述物件狀態的轉換（例如：訂單從「待付款」轉為「已發貨」）。
* **對 PG 的價值：** 確保狀態變更符合邏輯，避免出現「未付款卻已發貨」的 Bug。

### 3. 程式開發 (Programmer/Coding, PG)
- **白話文：** 正式「動工蓋房子」。
- **核心任務：** 工程師根據設計圖寫出程式碼。根據 SA/SD 提供的圖表與文件，產出高品質的原始碼。
- **關鍵產出：** * **程式原始碼 (Source Code)**。
- **API 文件：** 告訴不同模組之間如何溝通的說明書。

### 4. 測試驗證 (Testing/QA)
- **白話文：** 檢查有沒有「漏水或裂縫」。
- **核心任務：** 由測試工程師 (QA) 尋找 Bug，確保軟體跑起來跟當初 SA 寫的規格書一模一樣。
- **關鍵產出：** * **測試報告 (Test Report)**、**缺陷報告 (Bug Report)**。

### 5. 部署與發布 (Deployment)
- **白話文：** 「交屋」讓使用者入住。
- **核心任務：** 將程式放到伺服器（正式環境），讓全世界或公司內部員工可以使用。
- **關鍵產出：** * **發布說明 (Release Notes)**、**使用者操作手冊**。

### 6. 維運與更迭 (Maintenance)
- **白話文：** 「售後服務」與房屋修繕。
- **核心任務：** 修復上線後才發現的小問題，或是根據使用者回饋進行微調。
- **關鍵產出：** * **維護單、工作記錄單**。
---

## 二、 快速對照表：任務與文件一覽

| **階段名稱** | **核心角色** | **關鍵任務** | **產出文件 (初學者必知)** | 核心 UML 工具 | 給 PG 的主要訊息 |
| ----------- | -------------- | ---------- | ------------------- | --------- | ------------ |
| **1. 需求分析** | **SA** (系統分析師) | 訪談、談判、收斂需求 | **SRS** (需求規格說明書) | 使用案例圖、活動圖 | 「要做哪些功能？」 |
| **2. 系統設計** | **SD** (系統設計師) | 規畫架構、資料結構 | **DDS** (設計說明書) | 類別圖、循序圖 | 「程式與資料庫怎麼寫？」 |
| **3. 開發實作** | **PG** (程式設計師) | 撰寫程式碼 | **API 文件**、原始碼 | | 實作功能 |
| **4. 測試階段** | **QA** (測試工程師) | 找 Bug、壓力測試 | **測試報告**、Bug Report | | 「有沒有寫錯？」 |
| **5. 部署發布** | **OP/DEVOPS** | 上線部署 | **使用者手冊** | | 「如何讓大家使用？」 |
| **6. 維護更迭** | Maintenance | 備份、修復、微調 | **維護單、工作記錄單** | | |

**初學者小撇步：**
並非每個專案都要畫完所有的 UML 圖。
- 如果你是**後端開發**，請務必看懂 **類別圖** 與 **循序圖**。
- 如果你是**前端開發**，**活動圖** 與 **使用案例圖** 對理解操作流程最有幫助。
- **小專案：** 活動圖 + 簡單的類別圖（或資料庫 Schema）就足夠了。
- **複雜專案：** 務必加入循序圖，因為這能最有效地減少 PG 在處理多物件互動時的混亂。
---

## 三、 常見 Q&A

**Q：為什麼需要這麼多文件？直接寫程式不是比較快嗎？**

> **A：** 軟體開發最怕「雞同鴨講」。文件是為了讓 SA、SD、PG 之間有共同的語言。如果沒有文件，開發到一半發現需求理解錯誤，打掉重練的成本會是原本的數十倍。

**Q：開發模型有哪些？**

> **A：** 常見的有2種類：
> - **瀑布流 (Waterfall)：** 一步一腳印，做完第一步才做第二步（適合大型且需求明確的政府專案）。
> - **敏捷式 (Agile)：** 快速開發、快速修錯，每兩週就出一個小版本（適合市場變化快的新創產品）。