軟體工程-應用“瀑布模型”進行開發

如果您喜歡這些文章，歡迎點擊此處訂閱本Blog

概述

    瀑布模型其實並不新，它在1970年前後就已經出現了，但是大部分開發人員對瀑布模型只有一個模糊的概念。從本質來講，它是一個軟體開發架構，開發過程是通過一系列階段順序展開的，從系統需求分析開始直到產品發布和維護，每個階段都會產生迴圈反饋，因此，如果有資訊未被覆蓋或者發現了問題，那麼最好 “返回”上一個階段並進行適當的修改，開發進程從一個階段“流動”到下一個階段，這也是瀑布開發名稱的由來。

    這一模型存在很多變體，每種只是在階段名稱上略有區別，但是，總體來講，瀑布開發模型可以分為六個不同的階段，其定義如下：

    1.需求分析：雖然是第一步，但是這一步至關重要，因為它包含了擷取客戶需求與定義的資訊，以及對需要解決的問題所能達到的最清晰的描述。分析包含了理解客戶的商業環境與約束，產品必需實現的功能，產品必需達到的效能水平，以及必需實現相容的外部系統。

    在這一階段所使用的技術包括採訪客戶、使用案例和軟體特色的“購物清單”。分析階段的結果通常是一份正式的需求說明書，這也是下一階段的起始資訊資料。

    2.設計：這一步包括了“定義硬體和軟體架構、組件、模組、介面和資料等來滿足指定的需求(Wikipedia)。”它包括了硬體和軟體架構的定義，確定效能和安全參數，設計資料存放區容器和限制，選擇整合式開發環境（IDE）和程式設計語言，並指定異常處理、資源管理和介面串連性的策略。

這一階段還強調了使用者介面的設計，包括與瀏覽和可用性相關的問題，這一階段的輸出結果是一份或多份設計說明書，這些說明書將在下一階段使用。

    3.實現：這一步包含了根據設計說明書來構建產品，通常，這一階段是由Team Dev來執行的，Team Dev包括了程式員、介面設計師和其他的專家，他們使用的工具包括編譯軟體、調試軟體、解釋軟體和媒體編輯軟體。

    這一階段將產生一個或多個產品組件，它們是根據每一條編碼通訊協定而編寫的，並且經過了調試、測試並進行整合以滿足系統架構的需求。對於大型Team Dev而言，我建議使用版本控制工具來追蹤代碼樹的變化，這樣在出現問題的時候可以還原以前的版本。

    4.測試：在這一階段，獨立的組件和整合後的組件都將進行系統性驗證以確保沒有錯誤並且完全符合第一階段所制定的需求。一個獨立的品質保證小組將定義“測試執行個體”來評估產品是完全實現了需求還是只有部分滿足。

    有三種測試方法可以使用：對獨立的代碼模組進行單元測試；對整合產品進行系統測試；以及客戶參與的驗收測試。如果發現了缺陷，將會對問題進行記錄並向Team Dev反饋以進行修正。在這一階段，還有產品文檔會經過準備、評估並發布，比如使用者手冊等。

    5.安裝：在產品通過測試並且被評鑑為符合需求的產品後，就會進入到安裝階段，這一階段包括了在客戶網站進行系統或產品的安裝和使用，這可以通過互連網或者物理媒介進行，通常交付使用的產品都帶有正式的版本號碼，這為今後的產品升級提供了便利。

    6. 維護：這一階段發生在安裝之後，包括了對整個系統或某個組件進行修改以改變屬性或者提升效能，這些修改可能源於客戶的需求變化或者系統使用中沒有覆蓋到的缺陷，通常，在維護階段對產品的修改都會被記錄下來併產生新的發布版本（稱作“維護版本”並伴隨升級了的版本號碼）以確保客戶可以從升級中獲益。

優勢

    上述的瀑布模型為軟體開發人員提供了眾多優勢，首先，這個階段性的軟體開發模型規定了以下規則：每個階段都有指定的起點和終點，過程最終可以被客戶和開發人員識別（通過使用裡程碑），在編寫第一行代碼之前充分強調了需求和設計，這避免了時間的浪費以及跳票的風險，同時還可以儘可能地保證實現客戶的預期需求。

    提取需求和設計提高了產品品質，因為在設計階段捕獲並修正可能存在的漏洞要比測試階段容易很多，畢竟在組件整合之後來追蹤特定的錯誤要複雜很多。最後，因為前兩個階段產生了規範的說明書，當團隊成員分散在不同地點的時候，瀑布模型可以協助實現有效知識傳遞。

缺點

    除了看上去很明顯的這些優勢，瀑布模型近來也受到了很多批評，最突出的一點是圍繞需求分析的，通常客戶一開始並不知道他們需要的是什麼，而是在整個項目進程 中通過雙向互動不斷明確的；而瀑布模型是強調捕獲需求和設計的，但在這種情況下，現實世界的反覆無償就顯得瀑布模型有些不切實際了。

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

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

    有些批評還指出瀑布模型暗示了清晰的分工，將參與開發的人員分為“設計師”、“程式員”和“測試員”，但是在現實中，這樣的分工對於軟體公司而言既不現實也沒有效率。

客戶需求

    儘管瀑布模型招致了很多批評，但是它對很多類型的項目而言依然是有效，如果正確使用，可以節省大量的時間和金錢。對於您的項目而言，是否使用這一模型主要 取決於您是否能理解客戶的需求以及在項目的進程中這些需求的變化程度，對於經常變化的項目而言，瀑布模型毫無價值，對於這種情況，您可以考慮其他的架構來 進行專案管理，比如名為螺旋模型（spiral model）的方法，當然，這是另外一碼事了，也許我們以後會講到這些方法。