作者｜瞻新資訊 張安邦執行長（台大醫工背景・十年以上IT服務公司創辦人）
企業主找廠商談系統開發，聊到一半，對方說「我們這個專案會用敏捷式開發，每兩週會有一次交付」。企業主點點頭，心裡卻沒底：這代表什麼？是比較快、還是比較貴？跟另一家廠商說的「我們照SOP走瀑布式流程」，到底哪個比較適合自己？
這些詞背後其實都指向同一件事：系統開發生命週期，英文縮寫SDLC（Software Development Life Cycle）。這篇文章會用白話講清楚SDLC是什麼、有哪些階段，也會說明瀑布式跟敏捷式差在哪、該怎麼選，讓你下次聽到廠商講這些詞的時候，知道自己該期待什麼。
系統開發生命週期是什麼？先講白話版本
白話講，系統開發生命週期就是做一套系統，從想法到真正能用，中間會經過哪幾個固定階段的整套流程架構。不管廠商用什麼方法論、講什麼專有名詞，最終都逃不出這幾個大方向：先搞清楚要做什麼、再設計怎麼做、然後動手做、做完要驗證有沒有做對、驗證過了才讓使用者開始用、上線之後還要持續維護。
正式一點講，這套流程架構在國際上有對應的標準可循，也就是ISO/IEC/IEEE 12207國際標準，定義了軟體系統從概念發想到最終淘汰的完整流程框架，不管是傳統的瀑布式、還是近年常聽到的敏捷式，都能對應到這套框架底下的流程分類。這套標準官方說明的存在目的，是提供一套定義明確的流程，促進委託方、供應方與其他利害關係人在軟體產品生命週期中的溝通。換句話說，它一開始的設計初衷，就包含了讓出錢的一方（企業主）跟做事的一方（開發廠商）能夠對齊認知、講同一套語言，不是只給工程師內部參考用的技術文件。也就是說，SDLC不是某家廠商自創的一套講法，而是有國際共識支撐的做事邏輯。
SDLC有哪些階段？從需求分析到維護
不同資料對階段的命名可能有些微差異，但核心大致是這六個：
- 需求分析：釐清要解決什麼問題、系統要做到什麼程度、使用者是誰。
- 規劃與設計：決定系統架構、資料庫怎麼設計、介面長什麼樣子。
- 開發（實作）：工程師實際寫程式、建置功能。
- 測試：驗證做出來的東西符不符合當初的需求，抓出裡面的錯誤。
- 部署（上線）：正式讓使用者開始使用這套系統。
- 維護：上線之後持續修正錯誤、調整功能、優化效能。
這六個階段，瀑布式跟敏捷式都會經過，差別在於怎麼安排這幾個階段之間的關係，這也是下一節要談的重點。
瀑布式跟敏捷式差在哪？該怎麼選
瀑布式（Waterfall）是最傳統的做法，顧名思義像瀑布一樣，水只會往下流，不會逆流——上面那六個階段，一個做完才進下一個，前面的階段沒做完，後面不會開始。這種做法的好處是進度容易掌握、每個階段的產出很清楚；缺點是一旦中途發現需求需要調整，往回修改的成本會很高，因為後面的階段都已經蓋在前面的基礎上了。
敏捷式（Agile）則是把整個專案拆成一個一個短週期，通常叫Sprint，兩週到一個月不等，每個短週期裡面都會重複經過小型的設計、開發、測試循環，逐步交付出一部分一部分可以用的功能，而不是等到全部做完才一次交付。這種做法的好處是能快速回應需求變化，也能提早看到部分成果；缺點是對團隊協作方式與客戶的參與度要求比較高，客戶如果沒辦法在專案過程中持續給回饋，敏捷式的優勢會發揮不出來。
| 項目 | 瀑布式（Waterfall） | 敏捷式（Agile） |
|---|---|---|
| 執行方式 | 線性、依序完成 | 迭代、短週期反覆進行 |
| 需求變動彈性 | 低，中途改需求成本高 | 高，可隨每個週期調整 |
| 適合專案 | 需求明確、變動少、結果可預期 | 需求會隨市場調整、想快速上市 |
| 優點 | 簡單易懂、進度容易掌握 | 能快速回應變化、及早交付可用版本 |
| 缺點 | 缺乏彈性，前期需求沒抓對後果大 | 對團隊協作與客戶參與度要求較高 |
別把瀑布式當過時、敏捷式當先進：選擇看專案性質，不是看誰比較潮
網路上不少文章會把敏捷式寫成先進、瀑布式寫成過時，這種二分法其實不太準確。兩者沒有絕對的優劣，關鍵在於專案性質適不適合。
舉例來說，如果要開發的是一套規格已經很明確、幾乎不會變動的內部作業系統，例如公司的請假簽核流程數位化，需求本來就穩定，瀑布式反而簡單直接，不需要為了敏捷而增加額外的溝通與管理成本。反過來，如果是一個要對外經營、市場反應會不斷影響功能方向的產品，例如一個電商平台或會員系統，需求本來就會隨著上線後的使用者回饋持續調整，這時候敏捷式讓你能夠邊做邊修正方向，會比死板地照著一開始的規格走到底更務實。
選錯方法論的常見後果是：需求本來就會一直變動的專案硬套瀑布式，容易在後期才發現方向早就錯了，卻已經來不及回頭修正；反過來，需求本來很單純明確的專案硬套敏捷式，可能徒增溝通與管理成本，多繳了不必要的學費。
委外開發時，懂SDLC對你有什麼實際幫助
多數企業主不需要自己動手寫程式，但懂一點SDLC的邏輯，對委外合作有實際的幫助，這也呼應了前面提到的，這套標準原本的設計目的之一，就是促進委託方與供應方之間的溝通。
第一，聽得懂廠商在講什麼。廠商說這是Sprint 2的交付、我們現在在做需求訪談，你能知道現在專案走到哪個階段，而不是完全狀況外。
第二，判斷延期合不合理。如果廠商在需求分析階段就一直拖，代表連要做什麼都還沒確定清楚，這時候擔心進度是合理的；但如果是敏捷式專案在某個Sprint裡調整了功能方向，這反而是正常的迭代過程，不代表專案出問題。
第三，知道自己該扮演什麼角色。瀑布式專案裡，你在需求確認階段要把關要清楚、講明白，之後修改的空間有限；敏捷式專案裡，你需要在整個過程中持續參與、持續給回饋，才能真正發揮敏捷式的優勢。
不管哪種方法論，這個階段做不好，後面都要付出代價
不管選瀑布式還是敏捷式，有一件事是共通的：需求分析階段沒有做扎實，後面所有階段的修正成本都會被放大。
這是軟體工程界普遍的共識，也是中小企業自行委外開發系統時最容易輕忽的一步。很多企業主急著想看到畫面、想看到系統長什麼樣子，卻在最一開始到底要解決什麼問題這件事上講得不夠清楚，等到開發到一半才發現方向不對，回頭修改的成本往往比一開始多花時間釐清需求高出許多。花時間在需求分析階段把問題想清楚，看起來進度比較慢，實際上是整個專案最划算的投資。找對懂系統開發的專業團隊協助釐清這一步，往往比事後修正省下更多成本。
FAQ
系統開發生命週期是什麼？
系統開發生命週期（SDLC）是一套系統從想法到真正能用，中間會經過哪幾個固定階段的流程架構，通常包含需求分析、規劃設計、開發、測試、部署、維護六個階段，不管採用哪種開發方法論都會經過這些階段。
瀑布式跟敏捷式，我該選哪一個？
看你的專案需求穩不穩定。需求明確、變動少、結果可預期的專案適合瀑布式；需求會隨市場調整、想快速上市並持續修正方向的專案適合敏捷式。沒有絕對的優劣，關鍵是跟專案性質搭不搭。
敏捷式是不是比較先進、比較好？
不是。敏捷式跟瀑布式沒有優劣之分，只有適不適合。需求本來就穩定的專案硬套敏捷式，反而會增加不必要的溝通與管理成本。
SDLC每個階段大概要花多久？
沒有固定答案，取決於系統的規模與複雜度。一般來說，需求分析與規劃設計階段值得花足夠的時間釐清，因為這個階段的疏漏，會在後面的開發與測試階段被放大成更高的修正成本。
我自己不懂技術，需要懂SDLC嗎？
不需要懂到能自己開發，但了解基本邏輯有幫助。ISO/IEC/IEEE 12207國際標準本身的設計目的之一，就是促進委託方與供應方之間的溝通，懂SDLC能讓你聽懂廠商在講什麼階段、判斷進度延遲合不合理、知道自己在專案裡該扮演什麼角色，這些都是委外合作時實際用得到的判讀能力。
系統開發常常delay，是哪個階段最容易出問題？
需求分析階段最容易被輕忽，卻也是後續delay的常見源頭。這個階段沒有把要解決什麼問題講清楚，開發到一半才發現方向不對，回頭修改的成本會遠高於一開始多花的溝通時間。
參考資料
ISO/IEC/IEEE 12207 – Software Life Cycle Processes｜ANSI Blog｜https://blog.ansi.org/ansi/iso-iec-ieee-12207-2026-software-life-cycle/
ISO/IEC/IEEE 12207:2017 – Systems and software engineering — Software life cycle processes｜ISO官方｜https://www.iso.org/standard/63712.html
很多客戶來找我們的時候，其實說不清楚自己的需求，只知道現在的流程卡卡的、想找人做一套系統解決問題。這沒有關係，先把問題想清楚、再決定用哪種方式開發，是瞻新資訊在系統開發專案裡經常在做的第一步。
關於作者｜張安邦執行長
台灣大學醫學工程研究所背景，十年以上軟體開發經歷，領軍瞻新資訊有限公司（2010年成立），完成專案200＋、涵蓋40～50＋個產業。專長：網頁設計、APP開發、UI／UX設計、LINE Bot自動化、系統開發、資訊安全。
