SDLC 軟體開發生命週期總覽

是什麼？

SDLC（Software Development Life Cycle，軟體開發生命週期）是一套描述「軟體從構想到下線」全過程的結構化框架。它把混沌的開發工作切成可管理、可交接、可量測的階段，讓團隊對「現在在哪、產出什麼、誰負責」有共同語言。

身為資深 C# 開發者，你可能已經在 Visual Studio 裡按過無數次 F5，但 SDLC 關注的不是某一行程式碼，而是「整個交付流程」。它的價值在於：

• 降低風險：在早期用便宜的文件與討論發現問題，而不是上線後用真金白銀補救。
• 可預測性：管理層能估時程、估成本、估資源。
• 可追溯性：每個功能都能往回追到當初的需求，往下對應到測試案例。

六大階段詳解

每個階段都有明確的「輸入 → 活動 → 產出 → 負責角色」。理解這四個面向，才能在任何專案中辨認自己身處哪一階段。

各階段的實務重點

• 需求：這是整條生命週期中錯誤成本最低、修正最便宜的時刻。一句話沒問清楚，可能讓後面五個階段全部走偏。
• 設計：把「要做什麼」翻譯成「怎麼做」。對 C# 專案而言，這裡會決定分層架構、是否導入 CQRS、ORM 選型、邊界上下文（Bounded Context）切分。
• 開發：實際產出程式碼。好的團隊在此階段就把單元測試、靜態分析（如 Roslyn Analyzer）、Code Review 內建進流程。
• 測試：不只是「找 Bug」，更是「驗證系統符合需求」。注意測試左移（Shift-Left），愈早測愈省。
• 部署：現代實務以 CI/CD 自動化為主，搭配藍綠部署或金絲雀發佈降低上線風險。
• 維運：軟體生命週期中最長的階段，往往佔總成本 60% 以上，而且會持續餵出新需求。

需求階段：四個活動怎麼做

• 訪談：對利害關係人做半結構式訪談。先開放式問題（「你現在怎麼處理請假？」）再收斂，用 5 Whys 挖真實痛點；問「現況與困擾」而非「你想要什麼功能」（使用者常直接丟解法）。
• 釐清：把模糊處轉成明確陳述，維護「假設清單（Assumptions）」與「待澄清問題（Open Questions）」，逐一找對的人確認。
• 優先排序：常用 MoSCoW、價值／成本矩陣、RICE、Kano 模型。
• 可行性評估：技術、經濟（ROI）、時程、營運四個面向逐一評估。

產出物（SRS、User Story、驗收條件）的完整內容與寫法，詳見本主題第 2 課《需求工程與 User Story》。

設計階段：四種產出物的內容與產出方式

ADR 範本（每個重大決策一個檔案）：

# ADR-007: 訂單查詢採用 Dapper 而非 EF Core
 
## Status
Accepted（2026-06）
 
## Context
訂單報表有大量複雜 SQL，EF Core 產生的查詢效能不佳且難調校。
 
## Decision
查詢路徑改用 Dapper 手寫 SQL；寫入路徑仍用 EF Core。
 
## Consequences
+ 報表查詢效能大幅提升、SQL 完全可控
- 團隊需同時維護兩套資料存取方式

ADR 是最被低估的工具：半年後有人問「為什麼這樣設計？」，ADR 就是答案，避免決策被反覆推翻。

設計階段常聽到的技術名詞

• CQRS（命令查詢職責分離）：把「寫入（改狀態）」與「讀取（查資料）」拆成兩條模型／路徑，讀寫各自最佳化，代價是複雜度上升。詳見 DDD 主題的 CQRS 一課。
• ORM 選型：ORM 把 C# 物件與資料表自動對映。.NET 兩大選擇是 EF Core（功能全、開發快、LINQ、自動 migration）與 Dapper（極輕、貼近 SQL、效能好但要自己寫 SQL）。選型即在「開發速度」與「效能／掌控度」間取捨。
• Bounded Context（限界上下文）：DDD 概念，把大系統依業務語意邊界切成數個獨立模型，每個邊界內名詞有一致意義。詳見 DDD 主題與本主題《系統切分》一課。
• 靜態分析（如 Roslyn Analyzer）：不執行程式、直接分析原始碼，用來抓 bug 風險、強制風格一致、揪安全漏洞，在編譯期／CI 就擋下低級錯誤，常搭 .editorconfig、SonarQube。

// 一段程式碼如何貫穿各階段的「可追溯性」示意
// 需求: US-142「使用者下單後應收到 Email 通知」
// 設計: 採用事件驅動，OrderPlaced 事件觸發通知服務
public sealed class OrderPlacedHandler : INotificationHandler<OrderPlaced>
{
    private readonly IEmailSender _email; // 設計階段定義的介面合約
 
    public OrderPlacedHandler(IEmailSender email) => _email = email;
 
    // 開發階段實作；測試階段對應 TC-142 驗收條件
    public async Task Handle(OrderPlaced e, CancellationToken ct)
    {
        await _email.SendAsync(e.CustomerEmail, "您的訂單已成立", ct);
    }
}

常見誤區

流程／步驟

下圖以循序方式呈現六大階段。請記得：在敏捷實務中，這六步是「每個衝刺迷你跑一輪」，而非整個專案只跑一次。

SDLC 模型比較

同一組階段，可以用不同節奏來跑。下表是四種經典模型的一句話精華：

架構圖／概念圖

下圖呈現 SDLC 的迭代循環本質：維運階段蒐集到的回饋與新需求，會重新流回需求階段，啟動下一輪循環。這正是「它不是一次走完的瀑布」的核心。

注意從「維運」回到「需求」那條邊：它把整個流程閉合成一個循環。每一次循環，產品都應該比上一輪更貼近使用者真正需要的東西。

實戰補充（Q&A）

Q：身為資深 C# 開發者，我每天都在寫程式（開發階段），為什麼還要懂整條 SDLC？ A：因為你寫的程式碼會被前後階段牽動。需求沒講清楚，你寫得再漂亮也是白工；設計階段的架構決策，決定你之後是輕鬆擴充還是天天救火；不懂部署與維運，你會寫出在本機跑得很好、上線就爆炸的程式。理解全局，你才能在 Code Review 與設計討論中提出真正有價值的意見，也才是 Senior 跟 Junior 的差別。

Q：敏捷團隊還需要設計階段嗎？看起來大家都直接開衝刺？ A：需要，但形式不同。敏捷不是「不設計」，而是「即時且足夠（Just Enough, Just In Time）的設計」。重大架構決策仍會用 ADR（Architecture Decision Record）記錄，只是不再寫幾百頁的前期設計文件，而是隨衝刺漸進演化。

Q：維運階段為什麼會「產出新需求」？感覺很反直覺。 A：因為使用者只有真正用了系統，才知道哪裡不順、還缺什麼。監控數據會揭露效能瓶頸，客服工單會揭露痛點，這些都會被整理成新的 User Story，重新進入需求階段。這就是 SDLC 是循環而非直線的最佳證明。

Q：DevOps、CI/CD 是不是取代了 SDLC？ A：不是取代，是「加速並自動化」其中的部署與部分測試階段。SDLC 描述「做什麼階段」，DevOps 描述「如何讓這些階段流動得更快更可靠」。兩者是不同層次，互補而非互斥。

理解測驗

重點整理