軟件瀑布模型開發(fā)過程

1、軟件開發(fā)瀑布模型概述瀑布模型其實并不新，它在 1970 年前后就已經(jīng)出現(xiàn)了，但是大部分開發(fā)者 對瀑布模型只有一個模糊的概念。從本質(zhì)來講，它是一個軟件開發(fā)架構(gòu)，開發(fā) 過程是通過一系列階段順序展開的，從系統(tǒng)需求分析開始直到產(chǎn)品發(fā)布和維 護，每個階段都會產(chǎn)生循環(huán)反饋，因此，如果有信息未被覆蓋或者發(fā)現(xiàn)了問 題，那么最好 “返回”上一個階段并進行適當?shù)男薷?，開發(fā)進程從一個階段 “流動 到下一個階段，這也是瀑布開發(fā)名稱的由來。這一模型存在很多變體，每種只是在階段名稱上略有區(qū)別，但是，總體來 講，瀑布開發(fā)模型可以分為六個不同的階段，其定義如下：1.需求分析：雖然是第一步，但是這一步至關(guān)重要，因為它包含了獲取

2、客戶需求與定義 的信息，以及對需要解決的問題所能達到的最清晰的描述。分析包含了理解客 戶的商業(yè)環(huán)境與約束，產(chǎn)品必需實現(xiàn)的功能，產(chǎn)品必需達到的性能水平，以及 必需實現(xiàn)兼容的外部系統(tǒng)。在這一階段所使用的技術(shù)包括采訪客戶、使用案例和軟件特色的 “購物清 單”。分析階段的結(jié)果通常是一份正式的需求說明書，這也是下一階段的起始信 息資料。2.設計：這一步包括了 “定義硬件和軟件架構(gòu)、組件、模塊、界面和數(shù)據(jù)等來滿足指 定的需求(Wikipedia)?！彼擞布蛙浖軜?gòu)的定義，確定性能和安全參 數(shù)，設計數(shù)據(jù)存儲容器和限制，選擇集成開發(fā)環(huán)境(ID日和編程語言，并指定 異常處理、資源管理和界面連接性的策略。

3、這一階段還強調(diào)了用戶接口的設計，包括與瀏覽和可用性相關(guān)的問題，這 一階段的輸出結(jié)果是一份或多份設計說明書，這些說明書將在下一階段使用。3.實現(xiàn)：這一步包含了根據(jù)設計說明書來構(gòu)建產(chǎn)品，通常，這一階段是由開發(fā)團隊 來執(zhí)行的，開發(fā)團隊包括了程序員、界面設計師和其他的專家，他們使用的工 具包括編譯軟件、調(diào)試軟件、解釋軟件和媒體編輯軟件。這一階段將生成一個或多個產(chǎn)品組件，它們是根據(jù)每一條編碼標準而編寫 的，并且經(jīng)過了調(diào)試、測試并進行集成以滿足系統(tǒng)架構(gòu)的需求。對于大型開發(fā) 團隊而言，我建議使用版本控制工具來追蹤代碼樹的變化，這樣在出現(xiàn)問題的 時候可以還原以前的版本。4.測試：在這一階段，獨立的組件和集成后

4、的組件都將進行系統(tǒng)性驗證以確保沒有 錯誤并且完全符合第一階段所制定的需求。一個獨立的質(zhì)量保證小組將定義 “測 試實例 ”來評估產(chǎn)品是完全實現(xiàn)了需求還是只有部分滿足。有三種測試方法可以 使用：對獨立的代碼模塊進行單元測試；對集成產(chǎn)品進行系統(tǒng)測試；以及客戶參 與的驗收測試。如果發(fā)現(xiàn)了缺陷，將會對問題進行記錄并向開發(fā)團隊反饋以進 行修正。在這一階段，還有產(chǎn)品文檔會經(jīng)過準備、評估并發(fā)布，比如用戶手冊 等。5.安裝：在產(chǎn)品通過測試并且被鑒定為符合需求的產(chǎn)品后，就會進入到安裝階段， 這一階段包括了在客戶站點進行系統(tǒng)或產(chǎn)品的安裝和使用，這可以通過互聯(lián)網(wǎng) 或者物理媒介進行，通常交付使用的產(chǎn)品都帶有正式的版本號

5、，這為今后的產(chǎn) 品升級提供了便利。6.維護：這一階段發(fā)生在安裝之后，包括了對整個系統(tǒng)或某個組件進行修改以改變 屬性或者提升性能，這些修改可能源于客戶的需求變化或者系統(tǒng)使用中沒有覆 蓋到的缺陷，通常，在維護階段對產(chǎn)品的修改都會被記錄下來并產(chǎn)生新的發(fā)布版本（稱作 “維護版本 ”并伴隨升級了的版本號）以確?？蛻艨梢詮纳壷蝎@、人益。優(yōu)勢上述的瀑布模型為軟件開發(fā)人員提供了眾多優(yōu)勢，首先，這個階段性的軟 件開發(fā)模型規(guī)定了以下規(guī)則：每個階段都有指定的起點和終點，過程最終可以被客戶和開發(fā)者識別（通 過使用里程碑），在編寫第一行代碼之前充分強調(diào)了需求和設計，這避免了時 間的浪費以及跳票的風險，同時還可以盡可能

6、地保證實現(xiàn)客戶的預期需求。提取需求和設計提高了產(chǎn)品質(zhì)量，因為在設計階段捕獲并修正可能存在的 漏洞要比測試階段容易很多，畢竟在組件集成之后來追蹤特定的錯誤要復雜很 多。最后，因為前兩個階段生成了規(guī)范的說明書，當團隊成員分散在不同地點 的時候，瀑布模型可以幫助實現(xiàn)有效的知識傳遞。缺點除了看上去很明顯的這些優(yōu)勢，瀑布模型近來也受到了很多批評，最突出 的一點是圍繞需求分析的，通?？蛻粢婚_始并不知道他們需要的是什么，而是 在整個項目進程中通過雙向交互不斷明確的；而瀑布模型是強調(diào)捕獲需求和設 計的，但在這種情況下，現(xiàn)實世界的反復無償就顯得瀑布模型有些不切實際 了。除此以外，即使給定了客戶需求，根據(jù)這些需求

7、在一定的精確性范圍內(nèi) （瀑布模型所建議的）估算時間和成本是非常困難的。因此，建議在客戶需求 可以在最初階段明確的情況下并且相對穩(wěn)定的項目中使用瀑布模型。另外的批評指出瀑布模型還假定設計可以被轉(zhuǎn)換為真實的產(chǎn)品，這往往導 致開發(fā)者在工作時陷入困境，通常，看上去合理可行的設計方案在現(xiàn)實中往往 代價昂貴或者異常艱難，從而需要重新設計，這樣就破壞了傳統(tǒng)瀑布模型中清 晰的階段界限。有些批評還指出瀑布模型暗示了清晰的分工，將參與開發(fā)的人 員分為 “設計師”、“程序員 ”和“測試員 ”，但是在現(xiàn)實中，這樣的分工對于軟件公 司而言既不現(xiàn)實也沒有效率?？蛻粜枨蟊M管瀑布模型招致了很多批評，但是它對很多類型的項目而言

8、依然是有效 的，如果正確使用，可以節(jié)省大量的時間和金錢。對于您的項目而言，是否使 用這一模型主要取決于您是否能理解客戶的需求以及在項目的進程中這些需求 的變化程度，對于經(jīng)常變化的項目而言，瀑布模型毫無價值，對于這種情況， 您可以考慮其他的架構(gòu)來進行項目管理，比如名為螺旋模型（spiralmodel）的方法，當然，這是另外一碼事了 .我的觀點對于需求不明確或經(jīng)常變動的情況，瀑布模型是不適應的，其實就是需求 確定，其實瀑布模型也不是很好的，因為人的思維過程是連續(xù)的，不可能一下 子考慮的很全面，因此如果在瀑布的不同階段使用不同的人員，很難保證這個 階段方案真的能滿足下一階段的要求，而瀑布模型恰恰要求做到這樣（因為它 不允許循環(huán)和迭代，有循環(huán)和迭代就不叫瀑布模型了，誰見過瀑布還會自己流 回山上的），這個要求是不符合人的思維習慣的。所以可操作的過程必須是有靈活性的，可以處理不同類型的項目（或者針 對不同類型的項目采用不同的過程），比如對于一個開發(fā)周期長的項目，清晰