對瀑布模型的認識及總結(jié)-宗燕山

1、號學/<名r£i師間教時導成指完獲件x 星一原理、方域易系用2013年課程論文報告設(shè)計題目對瀑布模型的認識及總結(jié)院系名稱 專業(yè)（班級）計算機科學與技術(shù)系 計算機科學與技術(shù)（1）宗燕山（1004013019）張家銳2013年7月對瀑布模型的認識及總結(jié)一、核心思想瀑布模型(waterfall model)從本質(zhì)上講，瀑布模型是一個軟件開發(fā)架構(gòu)，重 復(fù)應(yīng)用。按工序?qū)栴}化簡，將功能的實現(xiàn)和設(shè)計分開，便于分工協(xié)作。采用結(jié) 構(gòu)化分析與設(shè)計方法，將邏輯實現(xiàn)與物理實現(xiàn)分開，依照軟件生命周期自上而下、 相互銜接的順序，如同瀑布流水逐級向下開發(fā)的開發(fā)模型。b.瀑布模型(waterfall m6d

2、el)定義階段可行性研究與計劃百覿測試x淅江今漆拄結(jié)信堤供維護階段c、運行維護二、概述在軟件開發(fā)中典型的開發(fā)模型有：瀑布模型(waterfall model)；漸增 模型/演化/送代(incremental model)；原型模型(prototype model)；螺旋 模型(spiral model)；噴泉模型(fountain model)；智能模型(intelligent model) ; 7.混合模型(hybrid model) o瀑布模型其實并不新，它在1970年前后就已經(jīng)出現(xiàn)了，但是大部分開發(fā)者 對瀑布模型只有一個模糊的概念。從本質(zhì)來講，它是一個軟件開發(fā)架構(gòu)，開發(fā)過 程是通過一系列

3、階段順序展開的，從系統(tǒng)需求分析開始直到產(chǎn)品發(fā)布和維護，每 個階段都會產(chǎn)生循環(huán)反饋，因此，如果有信息未被覆蓋或者發(fā)現(xiàn)了問題，那么最 好“返回”上一個階段并進行適當?shù)男薷模_發(fā)進程從一個階段“流動”到下一 個階段，這也是瀑布開發(fā)名稱的由來。這一模型存在很多變體，每種只是在階段 名稱上略有區(qū)別，但是，總體來講，瀑布開發(fā)模型可以分為六個不同的階段，其 定義如下：1. 需求分析：雖然是第一步，但是這一步至關(guān)重要，因為它包含了獲取客戶 需求與定義的信總，以及對需要解決的問題所能達到的最清晰的描述。分析包含 丫理解客戶的商業(yè)環(huán)境與約束，產(chǎn)品必需實現(xiàn)的功能，產(chǎn)品必需達到的性能水平, 以及必需實現(xiàn)兼容的外部系統(tǒng)

4、。在這一階段所使用的技術(shù)包括采訪客戶、使用案 例和軟件特色的“購物清單”。分析階段的結(jié)果通常是一份正式的需求說明書， 這也是下一階段的起始信息資料。2. 設(shè)計：這一步包括了 “定義硬件和軟件架構(gòu)、組件、模塊、界面和數(shù)據(jù)等 來滿足指定的需求(wikipedia)?！彼擞布蛙浖軜?gòu)的定義，確定性能和 安全參數(shù)，設(shè)計數(shù)據(jù)存儲容器和限制，選擇集成開發(fā)環(huán)境(ide)和編程語言， 并指定異常處理、資源管理和界面連接性的策略。這一階段還強調(diào)了用戶接u的 設(shè)計，包括與瀏覽和可用性相關(guān)的問題，這一階段的輸出結(jié)果是一份或多份設(shè)計 說明書，這些說明書將在下一階段使用。3. 實現(xiàn)：這一步包含了根據(jù)設(shè)計說明書來

5、構(gòu)建產(chǎn)品，通常，這一階段是由開 發(fā)團隊來執(zhí)行的，開發(fā)團隊包括了程序員、界面設(shè)計師和其他的專家，他們使用 的工具包括編譯軟件、調(diào)試軟件、解釋軟件和媒體編輯軟件。這一階段將生成一 個或多個產(chǎn)品組件，它們是根據(jù)每一條編碼標準而編寫的，并且經(jīng)過了調(diào)試、測 試并進行集成以滿足系統(tǒng)架構(gòu)的需求。對于大型開發(fā)團隊而言，我建議使用版本 控制工具來追蹤代碼樹的變化，這樣在出現(xiàn)問題的時候可以還原以前的版木。4. 測試：在這一階段，獨立的組件和集成后的組件都將進行系統(tǒng)性驗證以確 保沒有錯誤并且完全符合第一階段所制定的需求。一個獨立的質(zhì)量保證小組將定 義“測試實例”來評估產(chǎn)品是完全實現(xiàn)了需求還是只有部分滿足。有三種測試

6、 方法可以使用：對獨立的代碼模塊進行單元測試；對集成產(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)品都帶有正式的版本號，這為今后的 產(chǎn)品升級提供了便利。6. 維護：這一階段發(fā)生在安裝之后，包括了對整個系統(tǒng)或某個組件進行修改 以改變屬性或者提升性能，這些修改可能源于客戶的需求變化或者系統(tǒng)使用

7、中沒 有覆蓋到的缺陷，通常，在維護階段對產(chǎn)品的修改都會被記澩不來并產(chǎn)生新的發(fā) 布版本（稱作“維護版本”并伴隨升級了的版本號）以確?？蛻艨梢詮纳壷蝎@ 益。二、瀑布模型幵發(fā)的優(yōu)缺點1. 優(yōu)點上述的瀑布模型為軟件開發(fā)人員提供了眾多優(yōu)勢，首先，這個階段性的軟件 開發(fā)模型規(guī)定了以下規(guī)則：每個階段都有指定的起點和終點，過程最終可以被客 戶和開發(fā)者識別（通過使用里程碑），在編寫第一行代碼之前充分強調(diào)了需求和 設(shè)計，這避免了時間的浪費以及跳票的風險，同吋還可以盡可能地保證實現(xiàn)客戶 的預(yù)期需求。提取需求和設(shè)計提高y產(chǎn)品質(zhì)量，因為在設(shè)計階段捕獲并修正可能 存在的漏洞耍比測試階段容易很多，畢竟在組件集成之后來追蹤

8、特定的錯誤要復(fù) 雜很多。最后，因為前兩個階段生成了規(guī)范的說明書，當團隊成員分散在不同地 點的時候，瀑布模型可以幫助實現(xiàn)有效的知識傳遞。2. 缺點除了看上去很明顯的這些優(yōu)勢，瀑布模型近來也受到了很多批評，最突出的 一點是圍繞需求分析的，通?？蛻粢婚_始并不知道他們需要的是什么，而是在整 個項目進程中通過雙向交互不斷明確的；而瀑布模型是強調(diào)捕獲需求和設(shè)計的， 但在這種情況下，現(xiàn)實世界的反復(fù)無償就顯得瀑布模型冇些不切實際了。除此以 外，即使給定了客戶需求，根據(jù)這些需求在一定的精確性范圍a （瀑布模型所建 議的）估算時間和成本是非常困難的。因此，建議在客戶需求可以在最初階段明 確的情況下并且和對穩(wěn)定的項

9、目中使用瀑布模型。另外的批評指出瀑布模型還假定設(shè)計可以被轉(zhuǎn)換為真實的產(chǎn)品，這往往導致 開發(fā)者在工作時陷入困境，通常，看上去合理可行的設(shè)計方案在現(xiàn)實中往往代價 昂貴或者異常艱難，從而需耍重新設(shè)計，這樣就破壞了傳統(tǒng)瀑布模型中清晰的階 段界限。有些批評還指出瀑布模型暗示了清晰的分工，將參與開發(fā)的人員分為“設(shè) 計師”、“程序員”和“測試員”，但是在現(xiàn)實中，這樣的分工對于軟件公司而言 既不現(xiàn)實也沒有效率。四、對于瀑布模型的看法對于需求不明確或經(jīng)常變動的情況，瀑布模型是不適應(yīng)的，其實就是需求確 定，其實瀑布模型也不是很好的，因為人的思維過程是連續(xù)的，不可能一下子考 慮的很全面，因此如果在瀑布的不同階段使用

10、不同的人員，很難保證這個階段方 案真的能滿足下一階段的要求，而瀑布模型恰恰要求做到這樣（因為它不允許循 環(huán)和迭代，冇循環(huán)和迭代就不叫瀑布模型了，誰見過瀑布還會自己流冋山上的）, 這個要求是不符合人的思維習慣的。所以可操作的過程必須是有靈活性的，可以處理不同類型的項目（或者 針對不同類型的項目采用不同的過程），比如對于一個開發(fā)周期長的項h，清晰 嚴謹?shù)奈臋n很重要，但對于一個快速開發(fā)的項目，就不能有太繁重的 paper work。所以關(guān)鍵是過程要能根據(jù)實際情況剪裁，同時過程要能被持續(xù) 地改進，試圖一步到位地建立和實施一個新的過程是很難成功的，過程改進是持 續(xù)的也意味著是漸進的，不要一次引進太多的變

11、化。在瀑布模型中，軟件開發(fā)的各項活動嚴格按照線性方式進行，當前活動接 受上一項活動的工作結(jié)果，實施完成所需的工作內(nèi)容。當前活動的工作結(jié)果需要 進行驗證，如果驗證通過，則該結(jié)果作為下一項活動的輸入，繼續(xù)進行下一項活 動，否則返回修改。瀑布模型強調(diào)文檔的作用，并要求每個階段都要仔細驗證。 但是，這種模型的線性過程太理想化，己不再適合現(xiàn)代的軟件開發(fā)模式，幾乎被 業(yè)界拋棄，其主要問題在于：（1）各個階段的劃分完全固定，階段之間產(chǎn)生大量的文檔，極大地增加了工作 量；（2）由于開發(fā)模型是線性的，用戶只有等到整個過程的末期才能見到開發(fā)成果， 從而增加了開發(fā)的風險；（3）早期的錯誤可能要等到開發(fā)后期的測試階段才能發(fā)現(xiàn)，進而帶來嚴重的后 果。但是我們應(yīng)該認識到，"線性"是人們最容易掌握并能熟練應(yīng)用的思想方法。 當人們碰到一個復(fù)雜的"非線性"問題時，總是千方百計地將其分解或轉(zhuǎn)