深入人心的瀑布開發

瀑布開發分為需求分析，方案設計，實施編碼，測試評估，運行維護五個階段，如下圖所示。瀑布開發的歷史悠久，并且非常的成熟，很多的傳統大型軟件公司，都在采用瀑布開發的開發模式。

總體來講，瀑布開發的優勢很明顯，瀑布開發的項目階段劃分非常的清晰，有檢查點，瀑布開發的流程非常的清晰，易于操作。瀑布開發的開發模式，已經經過很多公司，很多人員的檢驗，有非常成功的案例，所以說瀑布開發在相當長的一段時間內，都是主流的開發模式，深受大家的推崇。

那么說，瀑布開發有哪些應用場景？我們可以從以下三個方面來分析，首先是基礎應用軟件，大型信息系統居多。我曾經在某亞太地區最大的ERP供應商工作，以提供大型信息化系統服務為主，當時我們在項目上的開發模式就是瀑布開發。其次是軟件售出后升級、修復成本比較高的行業，比如說我們所用的操作系統，或者是我們購買的其他的信息化系統，在首次購買后，需要反復升級迭代的系統，也是瀑布開發的應用場景。最后是行業競爭節奏相對平緩的行業，比如說醫院的一些HIS、PACS、LIS系統，或者是政府單位采購的管理信息系統等，處于行業壟斷地位的軟件等等。

時代在變，軟件開發的模式及應用場景，也在發生著翻天覆地的變化，我們可以從以下幾個方面來進行分析：

l? 互聯網及移動互聯網逐漸興起，B/S架構的應用成為主流。就在多年前，我還在給甲方作實施的時候，那時候還存在著大量C/S架構的軟件，需要在用戶端安裝獨立的軟件，才能夠進行訪問。可現在，大家通過瀏覽器就可以訪問我們想要訪問的信息化系統，非常的方便。

l? 軟件的交付手段發生了重大變化，在線更新，網絡下載。原來我們的軟件是需要專業的軟件公司來升級和維護的，現在我們的大部分軟件，直接可以在互聯網應用市場下載后直接進行更新，不再需要軟件廠商派專業人員來進行更新，所以說，軟件的交付手段和更新方式也產生了很大的變化。

l? 競爭速度越來越快。軟件行業屬于人才積聚的行業，當然，也是人力資源成本非常高的一個行業，如果說你的軟件不能夠快速的響應市場的變化，占有一定的用戶數量或者擁有一定的變現能力，那很可能就會被迅速的淘汰掉。競爭速度在加快，你如果用傳統的瀑布開發模式，已經不能夠適應快速發展的需要。

所以說，瀑布開發的缺點日益突出，因為瀑布開發的響應周期過長，可能是三個月，可能是六個月，也可能是一年，這太長了。還有，對于瀑布開發來講，只有在項目生命周期的后期才能看到相對完整的交付結果，如果說一個產品的開發周期是六個月，那么只有在第六個月的時候才能夠看到最終的、可以試用的產品。在前幾個月，可能第一個月只能看到接口文檔，第二個月只能看到數據庫的設計，第三個月可能看到某些頁面設計，不到最后，是看不到完整的產品，這種等待對用戶來講是苦苦的煎熬啊！客戶的需求不斷變化，三個月之后客戶的需求和三個月之前客戶的需求，就可能產生巨大的變化，試想一下，在這3到6個月的開發周期后，當這個軟件做出來時，可能已經不太符合客戶的需求。

瀑布開發通過過多的強制完成日期和里程碑來跟蹤各個項目階段。瀑布開發中，我們會設置一些里程碑，但是缺點也很明顯，其交付的東西，不太符合現在”完成“的定義，只能是部分完成，并不能夠直接交給終端用戶使用。當然，瀑布開發還有其他的缺點，我們在此就不一一列舉了。

剛才我們談了一些瀑布開發的缺點和問題，那么說，我們要如何去解決這些問題呢？伴隨著敏捷的興起，相信，這些問題可以得到更好的解決，或者是可以得到一些緩解和優化，有兩個里程碑性的事件在這里和大家分享一下。首先是1995年，薩瑟蘭和施瓦伯，提出了SCRUM概念，其次是1999年10月，肯特.貝殼出版《極限編程解析》，代表著敏捷的興起，也代表著新的解決方案的端倪呈現。

敏捷開發

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。