提到“瀑布開(kāi)發(fā)”的時(shí)候，大部分人們可能會(huì )聯(lián)想到尼亞加拉瀑布下要進(jìn)行房地產(chǎn)開(kāi)發(fā)，然后，設想一下，當您告訴他們實(shí)際上瀑布開(kāi)發(fā)是一種包含多個(gè)階段的反復疊代的軟件開(kāi)發(fā)模型時(shí)，他們會(huì )多么驚訝。這篇文章將為您提供一份關(guān)于瀑布模型的簡(jiǎn)要介紹，解釋它是什么，應當怎樣工作以及可能導致項目失敗的原因。

    概述

    瀑布模型其實(shí)并不新，它在1970年前后就已經(jīng)出現了，但是大部分開(kāi)發(fā)者對瀑布模型只有一個(gè)模糊的概念。從本質(zhì)來(lái)講，它是一個(gè)軟件開(kāi)發(fā)架構，開(kāi)發(fā)過(guò)程是通過(guò)一系列階段順序展開(kāi)的，從系統需求分析開(kāi)始直到產(chǎn)品發(fā)布和維護，每個(gè)階段都會(huì )產(chǎn)生循環(huán)反饋，因此，如果有信息未被覆蓋或者發(fā)現了問(wèn)題，那么最好“返回”上一個(gè)階段并進(jìn)行適當的修改，開(kāi)發(fā)進(jìn)程從一個(gè)階段“流動(dòng)”到下一個(gè)階段，這也是瀑布開(kāi)發(fā)名稱(chēng)的由來(lái)。    這一模型存在很多變體，每種只是在階段名稱(chēng)上略有區別，但是，總體來(lái)講，瀑布開(kāi)發(fā)模型可以分為六個(gè)不同的階段，

其定義如下：

    1.需求分析：雖然是第一步，但是這一步至關(guān)重要，因為它包含了獲取客戶(hù)需求與定義的信息，以及對需要解決的問(wèn)題所能達到的最清晰的描述。分析包含了理解客戶(hù)的商業(yè)環(huán)境與約束，產(chǎn)品必需實(shí)現的功能，產(chǎn)品必需達到的性能水平，以及必需實(shí)現兼容的外部系統。

    在這一階段所使用的技術(shù)包括采訪(fǎng)客戶(hù)、使用案例和軟件特色的“購物清單”。分析階段的結果通常是一份正式的需求說(shuō)明書(shū)，這也是下一階段的起始信息資料。

    2.設計：這一步包括了“定義硬件和軟件架構、組件、模塊、界面和數據等來(lái)滿(mǎn)足指定的需求(Wikipedia)?！彼擞布蛙浖軜嫷亩x，確定性能和安全參數，設計數據存儲容器和限制，選擇集成開(kāi)發(fā)環(huán)境（IDE）和編程語(yǔ)言，并指定異常處理、資源管理和界面連接性的策略。

    這一階段還強調了用戶(hù)接口的設計，包括與瀏覽和可用性相關(guān)的問(wèn)題，這一階段的輸出結果是一份或多份設計說(shuō)明書(shū)，這些說(shuō)明書(shū)將在下一階段使用。

    3.實(shí)現：這一步包含了根據設計說(shuō)明書(shū)來(lái)構建產(chǎn)品，通常，這一階段是由開(kāi)發(fā)團隊來(lái)執行的，開(kāi)發(fā)團隊包括了程序員、界面設計師和其他的專(zhuān)家，他們使用的工具包括編譯軟件、調試軟件、解釋軟件和媒體編輯軟件。

    這一階段將生成一個(gè)或多個(gè)產(chǎn)品組件，它們是根據每一條編碼標準而編寫(xiě)的，并且經(jīng)過(guò)了調試、測試并進(jìn)行集成以滿(mǎn)足系統架構的需求。對于大型開(kāi)發(fā)團隊而言，我建議使用版本控制工具來(lái)追蹤代碼樹(shù)的變化，這樣在出現問(wèn)題的時(shí)候可以還原以前的版本。

    4.測試：在這一階段，獨立的組件和集成后的組件都將進(jìn)行系統性驗證以確保沒(méi)有錯誤并且完全符合第一階段所制定的需求。一個(gè)獨立的質(zhì)量保證小組將定義“測試實(shí)例”來(lái)評估產(chǎn)品是完全實(shí)現了需求還是只有部分滿(mǎn)足。

    有三種測試方法可以使用：對獨立的代碼模塊進(jìn)行單元測試；對集成產(chǎn)品進(jìn)行系統測試；以及客戶(hù)參與的驗收測試。如果發(fā)現了缺陷，將會(huì )對問(wèn)題進(jìn)行記錄并向開(kāi)發(fā)團隊反饋以進(jìn)行修正。在這一階段，還有產(chǎn)品文檔會(huì )經(jīng)過(guò)準備、評估并發(fā)布，比如用戶(hù)手冊等。

    5.安裝：在產(chǎn)品通過(guò)測試并且被鑒定為符合需求的產(chǎn)品后，就會(huì )進(jìn)入到安裝階段，這一階段包括了在客戶(hù)站點(diǎn)進(jìn)行系統或產(chǎn)品的安裝和使用，這可以通過(guò)互聯(lián)網(wǎng)或者物理媒介進(jìn)行，通常交付使用的產(chǎn)品都帶有正式的版本號，這為今后的產(chǎn)品升級提供了便利。

    6.維護：這一階段發(fā)生在安裝之后，包括了對整個(gè)系統或某個(gè)組件進(jìn)行修改以改變屬性或者提升性能，這些修改可能源于客戶(hù)的需求變化或者系統使用中沒(méi)有覆蓋到的缺陷，通常，在維護階段對產(chǎn)品的修改都會(huì )被記錄下來(lái)并產(chǎn)生新的發(fā)布版本（稱(chēng)作“維護版本”并伴隨升級了的版本號）以確?？蛻?hù)可以從升級中獲益。

    優(yōu)勢

    上述的瀑布模型為軟件開(kāi)發(fā)人員提供了眾多優(yōu)勢，首先，這個(gè)階段性的軟件開(kāi)發(fā)模型規定了以下規則：每個(gè)階段都有指定的起點(diǎn)和終點(diǎn)，過(guò)程最終可以被客戶(hù)和開(kāi)發(fā)者識別（通過(guò)使用里程碑），在編寫(xiě)第一行代碼之前充分強調了需求和設計，這避免了時(shí)間的浪費以及跳票的風(fēng)險，同時(shí)還可以盡可能地保證實(shí)現客戶(hù)的預期需求。

    提取需求和設計提高了產(chǎn)品質(zhì)量，因為在設計階段捕獲并修正可能存在的漏洞要比測試階段容易很多，畢竟在組件集成之后來(lái)追蹤特定的錯誤要復雜很多。最后，因為前兩個(gè)階段生成了規范的說(shuō)明書(shū)，當團隊成員分散在不同地點(diǎn)的時(shí)候，瀑布模型可以幫助實(shí)現有效的知識傳遞。

    缺點(diǎn)

    除了看上去很明顯的這些優(yōu)勢，瀑布模型近來(lái)也受到了很多批評，最突出的一點(diǎn)是圍繞需求分析的，通?？蛻?hù)一開(kāi)始并不知道他們需要的是什么，而是在整個(gè)項目進(jìn)程中通過(guò)雙向交互不斷明確的；而瀑布模型是強調捕獲需求和設計的，但在這種情況下，現實(shí)世界的反復無(wú)償就顯得瀑布模型有些不切實(shí)際了。

    除此以外，即使給定了客戶(hù)需求，根據這些需求在一定的精確性范圍內（瀑布模型所建議的）估算時(shí)間和成本是非常困難的。因此，建議在客戶(hù)需求可以在最初階段明確的情況下并且相對穩定的項目中使用瀑布模型。

    另外的批評指出瀑布模型還假定設計可以被轉換為真實(shí)的產(chǎn)品，這往往導致開(kāi)發(fā)者在工作時(shí)陷入困境，通常，看上去合理可行的設計方案在現實(shí)中往往代價(jià)昂貴或者異常艱難，從而需要重新設計，這樣就破壞了傳統瀑布模型中清晰的階段界限。

    有些批評還指出瀑布模型暗示了清晰的分工，將參與開(kāi)發(fā)的人員分為“設計師”、“程序員”和“測試員”，但是在現實(shí)中，這樣的分工對于軟件公司而言既不現實(shí)也沒(méi)有效率。

    客戶(hù)需求

    盡管瀑布模型招致了很多批評，但是它對很多類(lèi)型的項目而言依然是有效的，如果正確使用，可以節省大量的時(shí)間和金錢(qián)。對于您的項目而言，是否使用這一模型主要取決于您是否能理解客戶(hù)的需求以及在項目的進(jìn)程中這些需求的變化程度，對于經(jīng)常變化的項目而言，瀑布模型毫無(wú)價(jià)值，對于這種情況，您可以考慮其他的架構來(lái)進(jìn)行項目管理，比如名為螺旋模型（spiral model）的方法，當然，這是另外一碼事了，也許我們以后會(huì )講到這些方法。