<!-- Feedsky FEED發布代碼開始 -->
如果您喜歡這些文章，歡迎點擊此處訂閱本Blog
<!-- FEED自動發現標記開始 --> <link title="RSS 2.0" type="application/rss+xml" rel="alternate"> <!-- FEED自動發現標記結束 -->
<!--Google 468*60橫幅廣告開始--><script type="text/javascript"><!-- google_ad_client = "pub-7343546549496470"; google_ad_width = 468; google_ad_height = 60; google_ad_format = "468x60_as"; google_ad_type = "image"; //2007-07-26: CSDN google_ad_channel = "6063905817"; google_color_border = "6699CC"; google_color_bg = "E6E6E6"; google_color_link = "FFFFFF"; google_color_text = "333333"; google_color_url = "AECCEB"; google_ui_features = "rc:6"; //--> </script><script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"> </script><!--Google 468*60橫幅廣告結束-->
瀑布模型其實并不新，它在1970年前后就已經出現了，但是大部分開發者對瀑布模型只有一個模糊的概念。從本質來講，它是一個軟件開發架構，開發過程是通過一系列階段順序展開的，從系統需求分析開始直到產品發布和維護，每個階段都會產生循環反饋，因此，如果有信息未被覆蓋或者發現了問題，那么最好 “返回”上一個階段并進行適當的修改，開發進程從一個階段“流動”到下一個階段，這也是瀑布開發名稱的由來。
這一模型存在很多變體，每種只是在階段名稱上略有區別，但是，總體來講，瀑布開發模型可以分為 六個不同的階段 ，其定義如下：
1.需求分析： 雖然是第一步，但是這一步至關重要，因為它包含了獲取客戶需求與定義的信息，以及對需要解決的問題所能達到的最清晰的描述。分析包含了理解客戶的商業環境與約束，產品必需實現的功能，產品必需達到的性能水平，以及必需實現兼容的外部系統。
在這一階段所使用的技術包括采訪客戶、使用案例和軟件特色的“購物清單”。分析階段的結果通常是一份正式的需求說明書，這也是下一階段的起始信息資料。
2.設計： 這一步包括了“定義硬件和軟件架構、組件、模塊、界面和數據等來滿足指定的需求(Wikipedia)。”它包括了硬件和軟件架構的定義，確定性能和安全參數，設計數據存儲容器和限制，選擇集成開發環境（IDE）和編程語言，并指定異常處理、資源管理和界面連接性的策略。
這一階段還強調了用戶接口的設計，包括與瀏覽和可用性相關的問題，這一階段的輸出結果是一份或多份設計說明書，這些說明書將在下一階段使用。
3.實現： 這一步包含了根據設計說明書來構建產品，通常，這一階段是由開發團隊來執行的，開發團隊包括了程序員、界面設計師和其他的專家，他們使用的工具包括編譯軟件、調試軟件、解釋軟件和媒體編輯軟件。
這一階段將生成一個或多個產品組件，它們是根據每一條編碼標準而編寫的，并且經過了調試、測試并進行集成以滿足系統架構的需求。對于大型開發團隊而言，我建議使用版本控制工具來追蹤代碼樹的變化，這樣在出現問題的時候可以還原以前的版本。
4.測試： 在這一階段，獨立的組件和集成后的組件都將進行系統性驗證以確保沒有錯誤并且完全符合第一階段所制定的需求。一個獨立的質量保證小組將定義“測試實例”來評估產品是完全實現了需求還是只有部分滿足。
有三種測試方法可以使用：對獨立的代碼模塊進行單元測試；對集成產品進行系統測試；以及客戶參與的驗收測試。如果發現了缺陷，將會對問題進行記錄并向開發團隊反饋以進行修正。在這一階段，還有產品文檔會經過準備、評估并發布，比如用戶手冊等。
5.安裝： 在產品通過測試并且被鑒定為符合需求的產品后，就會進入到安裝階段，這一階段包括了在客戶站點進行系統或產品的安裝和使用，這可以通過互聯網或者物理媒介進行，通常交付使用的產品都帶有正式的版本號，這為今后的產品升級提供了便利。
6. 維護： 這一階段發生在安裝之后，包括了對整個系統或某個組件進行修改以改變屬性或者提升性能，這些修改可能源于客戶的需求變化或者系統使用中沒有覆蓋到的缺陷，通常，在維護階段對產品的修改都會被記錄下來并產生新的發布版本（稱作“維護版本”并伴隨升級了的版本號）以確保客戶可以從升級中獲益。
上述的瀑布模型為軟件開發人員提供了眾多優勢，首先，這個階段性的軟件開發模型規定了以下規則：每個階段都有指定的起點和終點，過程最終可以被客戶和開發者識別（通過使用里程碑），在編寫第一行代碼之前充分強調了需求和設計，這避免了時間的浪費以及跳票的風險，同時還可以盡可能地保證實現客戶的預期需求。
提取需求和設計提高了產品質量，因為在設計階段捕獲并修正可能存在的漏洞要比測試階段容易很多，畢竟在組件集成之后來追蹤特定的錯誤要復雜很多。最后，因為前兩個階段生成了規范的說明書，當團隊成員分散在不同地點的時候，瀑布模型可以幫助實現有效的知識傳遞。
除了看上去很明顯的這些優勢，瀑布模型近來也受到了很多批評，最突出的一點是圍繞需求分析的，通常客戶一開始并不知道他們需要的是什么，而是在整個項目進程 中通過雙向交互不斷明確的；而瀑布模型是強調捕獲需求和設計的，但在這種情況下，現實世界的反復無償就顯得瀑布模型有些不切實際了。
除此以外，即使給定了客戶需求，根據這些需求在一定的精確性范圍內（瀑布模型所建議的）估算時間和成本是非常困難的。因此，建議在客戶需求可以在最初階段明確的情況下并且相對穩定的項目中使用瀑布模型。
另外的批評指出瀑布模型還假定設計可以被轉換為真實的產品，這往往導致開發者在工作時陷入困境，通常，看上去合理可行的設計方案在現實中往往代價昂貴或者異常艱難，從而需要重新設計，這樣就破壞了傳統瀑布模型中清晰的階段界限。
有些批評還指出瀑布模型暗示了清晰的分工，將參與開發的人員分為“設計師”、“程序員”和“測試員”，但是在現實中，這樣的分工對于軟件公司而言既不現實也沒有效率。
盡管瀑布模型招致了很多批評，但是它對很多類型的項目而言依然是有效的，如果正確使用，可以節省大量的時間和金錢。對于您的項目而言，是否使用這一模型主要 取決于您是否能理解客戶的需求以及在項目的進程中這些需求的變化程度，對于經常變化的項目而言，瀑布模型毫無價值，對于這種情況，您可以考慮其他的架構來 進行項目管理，比如名為螺旋模型（spiral model）的方法，當然，這是另外一碼事了，也許我們以后會講到這些方法。
<!--新Google 468*60橫幅廣告開始--><script type="text/javascript"><!-- google_ad_client = "pub-7343546549496470"; /* 468x60, 創建于 08-8-6 */ google_ad_slot = "7368701459"; google_ad_width = 468; google_ad_height = 60; //--> </script><script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"> </script><!--新Google 468*60橫幅廣告結束-->
<!--新Google 468x15 橫鏈接單元開始--><script type="text/javascript"><!-- google_ad_client = "pub-7343546549496470"; /* 468x15 橫鏈接單元 */ google_ad_slot = "5785741422"; google_ad_width = 468; google_ad_height = 15; //--> </script><script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"> </script><!--新Google 468x15 橫鏈接單元結束-->
<!-- Google Reader shared發布代碼開始 --><script type="text/javascript" src="http://www.google.com/reader/ui/publisher.js"></script><script type="text/javascript" src="http://www.google.com/reader/public/javascript/user/00697638153916680411/state/com.google/broadcast?n=5&callback=GRC_p(%7Bc%3A%22green%22%2Ct%3A%22%5Cu8FD9%5Cu4E9B%5Cu6587%5Cu7AE0%5Cu4E5F%5Cu503C%5Cu5F97%5Cu4E00%5Cu770B%22%2Cs%3A%22false%22%7D)%3Bnew%20GRC"></script><!-- Google Reader shared發布代碼結束 -->
<!--Google 468*60橫幅廣告開始--><script type="text/javascript"><!-- google_ad_client = "pub-7343546549496470"; google_ad_width = 468; google_ad_height = 60; google_ad_format = "468x60_as"; google_ad_type = "image"; //2007-07-26: CSDN google_ad_channel = "6063905817"; google_color_border = "6699CC"; google_color_bg = "E6E6E6"; google_color_link = "FFFFFF"; google_color_text = "333333"; google_color_url = "AECCEB"; google_ui_features = "rc:6"; //--> </script><script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"> </script><!--Google 468*60橫幅廣告結束-->
概述
瀑布模型其實并不新，它在1970年前后就已經出現了，但是大部分開發者對瀑布模型只有一個模糊的概念。從本質來講，它是一個軟件開發架構，開發過程是通過一系列階段順序展開的，從系統需求分析開始直到產品發布和維護，每個階段都會產生循環反饋，因此，如果有信息未被覆蓋或者發現了問題，那么最好 “返回”上一個階段并進行適當的修改，開發進程從一個階段“流動”到下一個階段，這也是瀑布開發名稱的由來。
這一模型存在很多變體，每種只是在階段名稱上略有區別，但是，總體來講，瀑布開發模型可以分為 六個不同的階段 ，其定義如下：
1.需求分析： 雖然是第一步，但是這一步至關重要，因為它包含了獲取客戶需求與定義的信息，以及對需要解決的問題所能達到的最清晰的描述。分析包含了理解客戶的商業環境與約束，產品必需實現的功能，產品必需達到的性能水平，以及必需實現兼容的外部系統。
在這一階段所使用的技術包括采訪客戶、使用案例和軟件特色的“購物清單”。分析階段的結果通常是一份正式的需求說明書，這也是下一階段的起始信息資料。
2.設計： 這一步包括了“定義硬件和軟件架構、組件、模塊、界面和數據等來滿足指定的需求(Wikipedia)。”它包括了硬件和軟件架構的定義，確定性能和安全參數，設計數據存儲容器和限制，選擇集成開發環境（IDE）和編程語言，并指定異常處理、資源管理和界面連接性的策略。
這一階段還強調了用戶接口的設計，包括與瀏覽和可用性相關的問題，這一階段的輸出結果是一份或多份設計說明書，這些說明書將在下一階段使用。
3.實現： 這一步包含了根據設計說明書來構建產品，通常，這一階段是由開發團隊來執行的，開發團隊包括了程序員、界面設計師和其他的專家，他們使用的工具包括編譯軟件、調試軟件、解釋軟件和媒體編輯軟件。
這一階段將生成一個或多個產品組件，它們是根據每一條編碼標準而編寫的，并且經過了調試、測試并進行集成以滿足系統架構的需求。對于大型開發團隊而言，我建議使用版本控制工具來追蹤代碼樹的變化，這樣在出現問題的時候可以還原以前的版本。
4.測試： 在這一階段，獨立的組件和集成后的組件都將進行系統性驗證以確保沒有錯誤并且完全符合第一階段所制定的需求。一個獨立的質量保證小組將定義“測試實例”來評估產品是完全實現了需求還是只有部分滿足。
有三種測試方法可以使用：對獨立的代碼模塊進行單元測試；對集成產品進行系統測試；以及客戶參與的驗收測試。如果發現了缺陷，將會對問題進行記錄并向開發團隊反饋以進行修正。在這一階段，還有產品文檔會經過準備、評估并發布，比如用戶手冊等。
5.安裝： 在產品通過測試并且被鑒定為符合需求的產品后，就會進入到安裝階段，這一階段包括了在客戶站點進行系統或產品的安裝和使用，這可以通過互聯網或者物理媒介進行，通常交付使用的產品都帶有正式的版本號，這為今后的產品升級提供了便利。
6. 維護： 這一階段發生在安裝之后，包括了對整個系統或某個組件進行修改以改變屬性或者提升性能，這些修改可能源于客戶的需求變化或者系統使用中沒有覆蓋到的缺陷，通常，在維護階段對產品的修改都會被記錄下來并產生新的發布版本（稱作“維護版本”并伴隨升級了的版本號）以確保客戶可以從升級中獲益。
優勢
上述的瀑布模型為軟件開發人員提供了眾多優勢，首先，這個階段性的軟件開發模型規定了以下規則：每個階段都有指定的起點和終點，過程最終可以被客戶和開發者識別（通過使用里程碑），在編寫第一行代碼之前充分強調了需求和設計，這避免了時間的浪費以及跳票的風險，同時還可以盡可能地保證實現客戶的預期需求。
提取需求和設計提高了產品質量，因為在設計階段捕獲并修正可能存在的漏洞要比測試階段容易很多，畢竟在組件集成之后來追蹤特定的錯誤要復雜很多。最后，因為前兩個階段生成了規范的說明書，當團隊成員分散在不同地點的時候，瀑布模型可以幫助實現有效的知識傳遞。
缺點
除了看上去很明顯的這些優勢，瀑布模型近來也受到了很多批評，最突出的一點是圍繞需求分析的，通常客戶一開始并不知道他們需要的是什么，而是在整個項目進程 中通過雙向交互不斷明確的；而瀑布模型是強調捕獲需求和設計的，但在這種情況下，現實世界的反復無償就顯得瀑布模型有些不切實際了。
除此以外，即使給定了客戶需求，根據這些需求在一定的精確性范圍內（瀑布模型所建議的）估算時間和成本是非常困難的。因此，建議在客戶需求可以在最初階段明確的情況下并且相對穩定的項目中使用瀑布模型。
另外的批評指出瀑布模型還假定設計可以被轉換為真實的產品，這往往導致開發者在工作時陷入困境，通常，看上去合理可行的設計方案在現實中往往代價昂貴或者異常艱難，從而需要重新設計，這樣就破壞了傳統瀑布模型中清晰的階段界限。
有些批評還指出瀑布模型暗示了清晰的分工，將參與開發的人員分為“設計師”、“程序員”和“測試員”，但是在現實中，這樣的分工對于軟件公司而言既不現實也沒有效率。
客戶需求
盡管瀑布模型招致了很多批評，但是它對很多類型的項目而言依然是有效的，如果正確使用，可以節省大量的時間和金錢。對于您的項目而言，是否使用這一模型主要 取決于您是否能理解客戶的需求以及在項目的進程中這些需求的變化程度，對于經常變化的項目而言，瀑布模型毫無價值，對于這種情況，您可以考慮其他的架構來 進行項目管理，比如名為螺旋模型（spiral model）的方法，當然，這是另外一碼事了，也許我們以后會講到這些方法。
<!--新Google 468*60橫幅廣告開始--><script type="text/javascript"><!-- google_ad_client = "pub-7343546549496470"; /* 468x60, 創建于 08-8-6 */ google_ad_slot = "7368701459"; google_ad_width = 468; google_ad_height = 60; //--> </script><script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"> </script><!--新Google 468*60橫幅廣告結束-->
<!--新Google 468x15 橫鏈接單元開始--><script type="text/javascript"><!-- google_ad_client = "pub-7343546549496470"; /* 468x15 橫鏈接單元 */ google_ad_slot = "5785741422"; google_ad_width = 468; google_ad_height = 15; //--> </script><script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"> </script><!--新Google 468x15 橫鏈接單元結束-->
<!-- Google Reader shared發布代碼開始 --><script type="text/javascript" src="http://www.google.com/reader/ui/publisher.js"></script><script type="text/javascript" src="http://www.google.com/reader/public/javascript/user/00697638153916680411/state/com.google/broadcast?n=5&callback=GRC_p(%7Bc%3A%22green%22%2Ct%3A%22%5Cu8FD9%5Cu4E9B%5Cu6587%5Cu7AE0%5Cu4E5F%5Cu503C%5Cu5F97%5Cu4E00%5Cu770B%22%2Cs%3A%22false%22%7D)%3Bnew%20GRC"></script><!-- Google Reader shared發布代碼結束 -->
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
