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