所有軟件方法的祖先是waterfallmethodology。因為開發模塊的順序流程而被稱為瀑布法，瀑布法是通過控制閥門由壹系列活動組成的。這些控制閥決定壹個給定的活動是否已經完成，是否可以進入下壹個活動。需求階段處理決定了所有的軟件需求。設計階段決定了整個系統的設計。代碼是在代碼階段編寫的。然後對代碼進行測試。終於，產品發布了。
瀑布法模型最基本的批評就是瀑布法反饋事物發展的時間太長。軟件有些內容很好理解，有些則相反。所以，當用戶沒有很好的理解手頭的問題時，開發人員試圖先完成所有的需求(也就是把需求量化到實際的規格說明書中)是非常空難的。此外，如果需求中有錯誤，它會蔓延到設計階段，到代碼等等。同時在過程中壹般沒有真正的能力回報。因此，如果妳進入測試，發現設計的壹部分不工作，妳會做出改變並修復問題，但這種方法會失去設計活動的所有上下文——妳只是帶著目的作用於系統！
認識到這個問題，瀑布法已被修改成幾種形式。比如螺旋瀑布法，繼承使用了多個瀑布模型。這種方法縮短了生命周期的下降時間；換句話說，它提供了解決問題的叠代方案。
最終，人們無法擺脫瀑布法，因為它確實是壹種常規方法。首先，這個方法可以確定將要建造什麽。然後，決定如何建立這些。接下來，世界構建這些內容。您可以確保您實際上構建了您需要的東西(並成功地運行它)。
2.統壹流程
統壹過程基於處理系統的最重要的方面應用短期叠代開發。
開發壹個用例很少的調查文檔(即用戶與系統交互的簡要描述)，開始排除那些可能對整個系統的成功帶來風險的用例。只要合適，在開發過程中可以添加或刪除列。
統壹過程的四個階段定義如下:
Inception:系統還處於確定系統內容的階段——系統將完成什麽，系統的邊界是什麽。如果能很好的理解系統，那麽這個階段很短。
精化:架構的風險正在轉移到系統中。描述這個階段的壹種方法是，“妳解決了所有的問題了嗎？”或者“妳知道如何完成妳要完成的事情嗎？”
Construction()正在完成所有相關欄目，為系統進行移交做準備，即進入測試版。
過渡使系統通過最終發布階段和測試版本。它可能包括軟件的操作和維護。
這是壹個關註於維護元素的敏捷過程，但是它仍然采用了大量的傳統實踐，例如用例開發和中間件。
3.極限編程:
極限編程的開發過程是以代碼為中心的方法。
讓用戶告訴妳系統是如何被故事描述的，並根據故事的重要性定制這些系統，這樣妳就可以為妳的團隊提供壹個故事的集合，妳可以在給定的叠代中完成它們，持續兩周左右——每周工作40小時。妳會對團隊進行劃分，雙人處理每個故事，並在編寫代碼時提供壹定數量的內置同行評審。您和您的合作夥伴在編寫自己的代碼時編寫單元測試。完成我負責的代碼後，拿到集成機上，放入代碼基線，運行從大家的代碼中積累的單元測試。在完成iji負責的代碼後，會提供壹個操作系統供用戶審查，以確保他們的工作符合他們的需求。
請註意，極限編程並沒有將軟件設計設置到高級階段。反而認為那些前端設計對整個系統開發幫助不是很大，最終會隨著實際開發進行修改。
極限編程非常適合需要持續提供運行系統的軟件卡。當缺乏用戶幹預或者項目很大時，極限編程將不會很好地工作，因為協調和設計活動實際上變得更加重要。
極限編程合理的考慮了開發社區的能力，這樣可以有效的規劃。