1、瀑布模型是由w.w.royce在2023年最初提出的軟體開發模型， 瀑布式開發是一種老舊的計算機軟體開發方法。
瀑布模型式是最典型的預見性的方法，嚴格遵循預先計畫的需求分析、設計、編碼、整合、測試、維護的步驟順序進行。
步驟成果作為衡量進度的方法，例如需求規格，設計文件，測試計畫和**審閱等等。
瀑布式的主要的問題是它的嚴格分級導致的自由度降低，專案早期即作出承諾導致對後期需求的變化難以調整，
代價高昂。瀑布式方法在需求不明並且在專案進行過程中可能變化的情況下基本是不可行的。
2、迭代式開發也被稱作迭代增量式開發或迭代進化式開發，是一種與傳統的瀑布式開發相反的軟體開發過程，它彌補了傳統開發方式中的一些弱點，具有更高的成功率和生產率。
什麼是迭代式開發？
每次只設計和實現這個產品的一部分,
逐步逐步完成的方法叫迭代開發,
每次設計和實現乙個階段叫做乙個迭代.
在迭代式開發方法中，整個開發工作被組織為一系列的短小的、
固定長度（如3周）的小專案，被稱為一系列的迭代。
每一次迭代都包括了需求分析、設計、實現與測試。
採用這種方法，開發工作可以在需求被完整地確定之前啟動，
並在一次迭代中完成系統的一部分功能或業務邏輯的開發工作。
再通過客戶的反饋來細化需求，並開始新一輪的迭代。
迭代式開發的優點：
1、降低風險
2、得到早期使用者反饋
3、持續的測試和整合
4、使用變更
5、提高復用性
螺旋開發，2023年，巴利·玻姆(barry boehm)正式發表了軟體系統開發的「螺旋模型」，它將瀑布模型和快速原型模型結合起來，強調了其他模型所忽視的風險分析，特別適合於大型複雜的系統。
「螺旋模型」剛開始規模很小，當專案被定義得更好、更穩定時，逐漸展開。
「螺旋模型」的核心就在於您不需要在剛開始的時候就把所有事情都定義的清清楚楚。您輕鬆上陣，定義最重要的功能，實現它，然後聽取客戶的意見，之後再進入到下乙個階段。如此不斷輪迴重複，直到得到您滿意的最終產品。
（1）制定計畫：確定軟體目標，選定實施方案，弄清專案開發的限制條件；
（2）風險分析：分析評估所選方案，考慮如何識別和消除風險；
（3）實施工程：實施軟體開發和驗證；
（4）客戶評估：評價開發工作，提出修正建議，制定下一步計畫。
螺旋模型很大程度上是一種風險驅動的方法體系，因為在每個階段之前及經常發生的迴圈之前，都必須首先進行風險評估。
敏捷軟體開發又稱敏捷開發，是一種從2023年代開始逐漸引起廣泛關注的一些新型軟體開發方法，是一種應對快速變化的需求的一種軟體開發能力。它們的具體名稱、理念、過程、術語都不盡相同，相對於「非敏捷」，更強調程式設計師團隊與業務專家之間的緊密協作、面對面的溝通（認為比書面的文件更有效）、頻繁交付新的軟體版本、緊湊而自我組織型的團隊、能夠很好地適應需求變化的**編寫和團隊組織方法，也更注重軟體開發中人的作用。
人和互動 重於過程和工具。可以工作的軟體 重於求全而完備的文件。客戶協作重於合同談判。隨時應對變化重於循規蹈矩。
其中位於右邊的內容雖然也有其價值，但是左邊的內容最為重要。
人員彼此信任 人少但是精幹 可以面對面的溝通
專案的敏捷開發：
敏捷開發小組主要的工作方式可以歸納為：作為乙個整體工作； 按短迭代週期工作； 每次迭代交付一些成果；
關注業務優先順序； 檢查與調整。
最重要的因素恐怕是專案的規模。規模增長，面對面的溝通就愈加困難，
因此敏捷方法更適用於較小的隊伍，40、30、20、10人或者更少。
大規模的敏捷軟體開發尚處於積極研究的領域。
四者對比區別：
傳統的瀑布式開發，也就是從需求到設計，從設計到編碼，從編碼到測試，從測試到提交大概這樣的流程，要求每乙個開發階段都要做到最好。
特別是前期階段，設計的越完美，提交後的成本損失就越少。
迭代式開發，不要求每乙個階段的任務做的都是最完美的，而是明明知道還有很多不足的地方，卻偏偏不去完善它，而是把主要功能先搭建起來為目的，以最短的時間，
最少的損失先完成乙個「不完美的成果物」直至提交。然後再通過客戶或使用者的反饋資訊，在這個「不完美的成果物」上逐步進行完善。
螺旋開發，很大程度上是一種風險驅動的方法體系，因為在每個階段之前及經常發生的迴圈之前，都必須首先進行風險評估。
敏捷開發，相比迭代式開發兩者都強調在較短的開發周期提交軟體，但是，敏捷開發的週期可能更短，並且更加強調隊伍中的高度協作。
敏捷方法有時候被誤認為是無計畫性和紀律性的方法，實際上更確切的說法是敏捷方法強調適應性而非預見性。
適應性的方法集中在快速適應現實的變化。當專案的需求起了變化，團隊應該迅速適應。這個團隊可能很難確切描述未來將會如何變化.
如果你沒有條件能與客戶時常溝通建議採用瀑布模型
1.需求分析
1.1 需求採集 粗粒度的收集材料
1.2 需求細化
1.2.1 選單確認 確認軟體應有的選單,功能等軟體先範圍資訊.
1.2.2 流程確認 確認軟體中有那工作流,重點繪製流程圖.
1.2.3 功能確認 確認每乙個功能點的具體需求.
2.軟體設計
2.1 er設計
2.2 原型設計
3.編碼實現
4.單元測試 研發人員自測
4.1 結對測試
4.2 用例測試
5.整合測試
5.1 通盤業務測試
5.1 邊界測試
5.2 壓力測試
5.3 資料介面測試
6.出廠評審 專案經理,研發經理,測試經理會簽.
7.軟體實施
7.1 業務資料維護
7.2 培訓
7.3 操作手冊編寫
8.軟體驗收
8.1 驗收報告
8.2 專案總結
把瀑布模型中的1-7變為3周左右的迴圈進行迭代推進,最好完成8
人和互動 重於過程和工具。
可以工作的軟體 重於求全而完備的文件。
客戶協作重於合同談判。
隨時應對變化重於循規蹈矩。
軟體開發模式對比 瀑布 迭代 螺旋 敏捷
1 瀑布模型是由w.w.royce在1970年最初提出的軟體開發模型，瀑布式開發是一種老舊的計算機軟體開發方法。瀑布模型式是最典型的預見性的方法，嚴格遵循預先計畫的需求分析 設計 編碼 整合 測試 維護的步驟順序進行。步驟成果作為衡量進度的方法，例如需求規格，設計文件，測試計畫和 審閱等等。瀑布式的...
軟體開發模式對比 瀑布 迭代 螺旋 敏捷
1 瀑布模型是由w.w.royce在1970年最初提出的軟體開發模型，瀑布式開發是一種老舊的計算機軟體開發方法。瀑布模型式是最典型的預見性的方法，嚴格遵循預先計畫的需求分析 設計 編碼 整合 測試 維護的步驟順序進行。步驟成果作為衡量進度的方法，例如需求規格，設計文件，測試計畫和 審閱等等。瀑布式的...
軟體開發模式對比 瀑布 迭代 螺旋 敏捷
1 瀑布模型是由w.w.royce在1970年最初提出的軟體開發模型，瀑布式開發是一種老舊的計算機軟體開發方法。瀑布模型式是最典型的預見性的方法，嚴格遵循預先計畫的需求分析 設計 編碼 整合 測試 維護的步驟順序進行。步驟成果作為衡量進度的方法，例如需求規格，設計文件，測試計畫和 審閱等等。瀑布式的...