瀑布式開發

瀑布式開發是一種老舊的，正在過時的計算機軟體開發方法。最開始的軟體行業普遍採用這種方法，但是這種方法套用自傳統工業生產，不適應計算機軟體開發的具體情況。

基本介紹

• 中文名：瀑布式開發
• 定義：老舊的計算機軟體開發方法
• 順序：需求、分析、設計、編碼、測試
• 舉例：需求規格，設計文檔，測試計畫

技術介紹

瀑布模型式是最典型的預見性的方法，嚴格遵循預先計畫的需求、分析、設計、編碼、測試的步驟順序進行。步驟成果作為衡量進度的方法，例如需求規格，設計文檔，測試計畫和代碼審閱等等。

瀑布式的主要的問題是它的嚴格分級導致的自由度降低，項目早期即作出承諾導致對後期需求的變化難以調整，代價高昂。瀑布式方法在需求不明並且在項目進行過程中可能變化的情況下基本是不可行的。

有論文統計他是造成70%軟體開發失敗的原因。

大體分為這幾個階段：需求分析、設計、編碼、測試、維護。

目標設計

需求階段通常定義系統的需求，明白系統的目標。

設計階段通常確定系統使用什麼資料庫，系統模組的劃分，各個模組的功能。

編碼階段用程式語言對設計階段的實現。

測試階段分黑盒測試，白盒測試。測試系統的功能是否實現，是否準確。

維護階段是根據用戶新的需要重新修改系統，使系統更加穩定，更符合用戶的要求。

需求階段的工作是否到位是整個系統開發的關鍵，在需求階段有很多方式可以幫助自己完成工作，例如與客戶暢所欲言，跟隨客戶參與業務過程等等。不管任何一種方法，任何一種方式，在需求階段首先確定系統邊界，確定組織邊界，然後摸清企業為消費者創造的價值，看清企業的價值鏈，摸清價值鏈上的實體。最後要平衡價值鏈上各個實體之間的利益，爭取系統做到大家都滿意這個理想的狀態。

與敏捷式對比

敏捷式vs.瀑布式：都需要經常，細緻的互動

團隊和利益相關者之間需要經常並且細緻的互動。建立互信，人們之間維持開放並且忠誠的關係非常重要。這樣的氛圍使得溝通更為有效，幫助大家構建對於正確需求的一致理解。

對於我來說，價值比費用更重要。如果你知道哪一個需求最為重要，那么開發它所需的成本反而不那么要緊。對價值的理解也會激勵大家，幫助大家關注於持續選擇並開發正確的需求。

使用敏捷項目框架，比如scrum、XP、SAFe或者LeSS並不會自動保證項目的成功。需要以適合項目需求的方式使用這些框架。選擇合適的方式，在工作方法上達成一致。不用太擔心項目一開始時達不到完美，反思之類的活動會幫助大家持續學習並在過程中不斷改進。