在瀑布模型中，軟件開發的各項活動嚴格按照線性方式進行，當前活動接受上一項活動的工作結果，實施完成所需的工作內容。當前活動的工作結果需要進行驗證，假如驗證通過，則該結果作為下一項活動的輸入，繼續進行下一項活動，否則返回修改。
瀑布模型強調文檔的作用，并要求每個階段都要仔細驗證。但是，這種模型的線性過程太理想化，已不再適合現代的軟件開發模式，幾乎被業界拋棄，其主要問題在于：
（1）各個階段的劃分完全固定，階段之間產生大量的文檔，極大地增加了工作量；
（2）由于開發模型是線性的，用戶只有等到整個過程的末期才能見到開發成果，從而增加了開發的風險；
（3）早期的錯誤可能要等到開發后期的測試階段才能發現，進而帶來嚴重的后果。
我們應該熟悉到，"線性"是人們最輕易把握并能熟練應用的思想方法。當人們碰到一個復雜的"非線性"問題時，總是千方百計地將其分解或轉化為一系列簡單的線性問題，然后逐個解決。一個軟件系統的整體可能是復雜的，而單個子程序總是簡單的，可以用線性的方式來實現，否則干活就太累了。線性是一種簡潔，簡潔就是美。當我們領會了線性的精神，就不要再呆板地套用線性模型的外表，而應該用活它。例如增量模型實質就是分段的線性模型，螺旋模型則是接連的彎曲了的線性模型，在其它模型中也能夠找到線性模型的影子。
在該模型的基礎上，還衍生出了強調測試活動的V模型。它把瀑布模型的測試階段進行細分，并于前面的階段進行對應。細分出來的這些階段分別為：單元測試階段、集成測試階段和系統測試階段。V模型的結構圖如下。
系統定義維護
-------\-----------------------/------------
需求分析.....系統測試
\/
概要設計.....集成測試
\/
具體設計...單元測試
\/
編碼
3.快速原型模型（RapidPrototypeModel）
快速原型模型的第一步是建造一個快速原型，實現客戶或未來的用戶與系統的交互，用戶或客戶對原型進行評價，進一步細化待開發軟件的需求。通過逐步調整原型使其滿足客戶的要求，開發人員可以確定客戶的真正需求是什么；第二步則在第一步的基礎上開發客戶滿足的軟件產品。
顯然，快速原型方法可以克服瀑布模型的缺點，減少由于軟件需求不明確帶來的開發風險，具有顯著的效果。
快速原型的要害在于盡可能快速地建造出軟件原型，一旦確定了客戶的真正需求，所建造的原型將被丟棄。因此，原型系統的內部結構并不重要，重要的是必須迅速建立原型，隨之迅速修改原型，以反映客戶的需求。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
