SDLC 七階段與模型解析

SDLC 是把軟體從規劃、開發到維護，拆成七個階段的流程。

說真的，這套東西很務實。IBM 提到，測試成本可能吃掉接近 33% 的系統開發費用。這代表你怎麼安排流程，不是管理層愛不愛開會的問題，而是錢會不會燒掉的問題。

很多團隊以為 SDLC 很老派。其實不然。它只是把混亂的軟體工作，變成可追蹤、可檢查、可交接的步驟。你如果做過專案，就知道少了這層結構，需求很容易飄，測試也很容易被砍。

SDLC 的重點，是把猜測變少

SDLC 的核心，就是把軟體開發變成一套可檢查的流程。它不是叫你寫更多文件。它是讓產品、工程、測試、營運和商務，對同一件事有共同語言。

IBM 的說法很實際。每個階段都要產出東西，下一階段才接得上。這樣做的好處很直接。需求不會一直漂，依賴關係比較不會漏，測試也不會被壓到最後一刻才做。

講白了，很多專案死得很普通。不是技術不行，而是前面沒想清楚。規劃太鬆，後面就一直補洞。分析太弱，範圍就一直長大。設計太粗，系統就很脆。SDLC 的價值，就是讓這些問題早點露出來。

• 規劃先定範圍與目標。
• 分析把業務需求變成技術需求。
• 設計處理架構、介面與依賴。
• 開發、測試、部署、維護接手落地。

七個階段看起來簡單，做起來很吵

IBM 把 SDLC 分成七階段：planning、analysis、design、coding、testing、deployment、maintenance。這個順序看起來很整齊，但真實專案通常不是照表操課。很多工作會重疊，也會反覆回頭修正。

規劃階段先定問題。分析階段把需求、資料、可行性和限制拆開。設計階段把這些東西變成架構、使用流程、資料庫和安全決策。接著才是 coding。testing 負責找缺陷與安全問題。deployment 把產品送到使用者手上。maintenance 則是讓它活下去。

你可能會想問，為什麼要分這麼細。因為每個階段都會把錯誤往下傳。規劃差，需求就模糊。分析差，範圍就失控。設計差，系統就難改。測試差，客服就會爆。維護差，產品就慢慢爛掉。

IBM 也提到，生成式 AI 可以用在規劃、分析、設計、coding 和 testing。這點很現實。AI 可以加快草稿、原型和測試案例生成，但它不會替你做判斷。人還是要看懂上下文，不然只是把錯誤更快放大。

“The software development lifecycle is a structured and iterative methodology used by development teams to build, deliver and maintain high-quality and cost-effective software systems.” — IBM

• 規劃決定做什麼，不做什麼。
• 分析決定需求是否站得住腳。
• 設計決定系統好不好擴充。
• 維護決定產品能活多久。

測試最花錢，也最能省錢

IBM 提到，測試可能占掉接近 33% 的系統開發成本。這數字很刺眼，但也很真實。很多團隊嘴上說重視品質，實際上卻把測試排到最後。結果就是上線後才開始付學費。

測試做太少，會出現 bug、效能問題和安全洞。測試做太多，也可能拖慢交付。問題不是要不要測，而是要在對的時間測對的東西。這就是 SDLC 的價值。

常見做法包括 unit testing、integration testing、system testing 和 acceptance testing。這些測試不是裝飾品。軟體很少單獨存在，它旁邊通常有 API、資料庫、身分系統、法規和營運限制。你只測單元，不代表整體能跑。

• Unit testing：驗證單一函式或模組。
• Integration testing：看模組之間能不能接起來。
• System testing：檢查整個產品在真實環境裡的表現。
• Acceptance testing：確認是否符合使用者與業務需求。

不同模型，會把流程切成不同節奏

SDLC 不是單一方法，而是一個框架。IBM 列出 waterfall、V-model、agile、lean、iterative、spiral、big bang 和 RAD。這些名字很多，但重點只有一個：你要用哪種節奏做決策。

Waterfall 是線性的。前一階段結束，下一階段才開始。Agile 比較迭代，階段可以重疊。DevOps 更進一步，把開發和營運接成一條持續流。若需求很穩定，線性模型可能夠用。若產品還在摸索，迭代模型通常比較合理。

選模型時，別被名詞唬住。真正該看的是需求清不清楚、專案複不複雜、團隊熟不熟、組織能不能接受變動。很多團隊把流程選錯，還怪工具不好。老實說，常常是流程跟問題根本不合。

• Waterfall 適合需求固定的專案。
• Agile 適合需要頻繁回饋的工作。
• DevOps 適合開發與營運要一起跑。
• RAD 適合快速原型與快速驗證。

SDLC 放到今天，重點是紀律，不是教條

我覺得 IBM 這篇最有用的地方，是它把 SDLC 拉回現實。這套流程不是拿來背的。它是拿來減少返工、減少風險、減少溝通失真。

現在很多團隊都在用生成式 AI。它可以幫忙寫需求草稿、產生 code snippet、整理測試案例。可是 AI 也會讓人更容易跳步驟。你如果少了 review、少了驗證、少了回饋，速度只會讓錯誤更快出現。

所以，現在選 SDLC 模型時，問題其實很簡單。你要的是可預測性，還是學習空間。答案不同，流程就該不同。這不是理論題，這是團隊每天都會碰到的決策。

如果你在做產品或帶工程團隊，我會建議先看你的測試節奏，再看你的交付節奏。流程對了，很多爭吵會少一半。流程不對，大家只會一直救火。

SDLC 不是舊東西，是把混亂管住的工具

SDLC 之所以一直有用，是因為軟體開發本來就容易亂。需求會變，依賴會變，團隊也會變。你不把流程寫清楚，最後就是靠記憶和運氣在撐。

IBM 的七階段講法，對新手很友善，對老手也有提醒。它不是要你把專案切得死死的，而是要你知道每一段在解什麼問題。這種框架感，對台灣很多正在做 SaaS、內部系統、AI 工具的團隊都很實用。

如果你現在正在選流程，我的建議很直接：先看需求穩不穩，再看測試能不能早做。只要這兩件事搞清楚，SDLC 就不會只是課本名詞，而會變成真的能省時間、也能省錢的工作方式。