定義
瀑布模型是将軟體生存周期的各項活動規定為按固定順序而連接配接的若幹階段工作,形如瀑布流水,最終得到軟體産品。
1970年溫斯頓·羅伊斯(Winston Royce)提出了著名的“瀑布模型”,直到80年代早期,它一直是唯一被廣泛采用的軟體開發模型。
核心思想
瀑布模型核心思想是按工序将問題化簡,将功能的實作與設計分開,便于分工協作,即采用結構化的分析與設計方法将邏輯實作與實體實作分開。将軟體生命周期劃分為制定計劃、需求分析、軟體設計、程式編寫、軟體測試和運作維護等六個基本活動,并且規定了它們自上而下、互相銜接的固定次序,如同瀑布流水,逐級下落。
重要地位
瀑布模型是最早出現的軟體開發模型,在軟體工程中占有重要的
瀑布模型
地位,它提供了軟體開發的基本架構。其過程是從上一項活動接收該項活動的工作對象作為輸入,利用這一輸入實施該項活動應完成的内容給出該項活動的工作成果,并作為輸出傳給下一項活動。同時評審該項活動的實施,若确認,則繼續下一項活動;否則傳回前面,甚至更前面的活動。對于經常變化的項目而言,瀑布模型毫無價值。
模型優缺點
瀑布模型有以下優點
1)為項目提供了按階段劃分的檢
瀑布模型
查點。
2)目前一階段完成後,您隻需要去關注後續階段。
3)可在疊代模型中應用瀑布模型。
增量疊代應用于瀑布模型。疊代1解決最大的問題。每次疊代産生一個可運作的版本,同時增加更多的功能。每次疊代必須經過品質和內建測試。
4)它提供了一個模闆,這個模闆使得分析、設計、編碼、測試和支援的方法可以在該模闆下有一個共同的指導。
(官方)瀑布模型有以下缺點
1)各個階段的劃分完全固定,階段之間産生大量的文檔,極大地增加了工作量。
2)由于開發模型是線性的,使用者隻有等到整個過程的末期才能見到開發成果,進而增加了開發風險。
3)通過過多的強制完成日期和裡程碑來跟蹤各個項目階段。
4)瀑布模型的突出缺點是不适應使用者需求的變化。
模型客戶需求
盡管瀑布模型招緻了很多批評,但是它對很多類型的項目而言依然是有效的,如果正确使用,可以節省大量的時間和金錢。對于您的項目而言,是否使用這一模型主要取決于您是否能了解客戶的需求以及在項目的程序中這些需求的變化程度,對于經常變化的項目而言,瀑布模型毫無價值,對于這種情況,您可以考慮其他的架構來進行項目管理,比如名為螺旋模型(spiral model)的方法。
在瀑布模型中,軟體開發的各項活動嚴格按照線性方式進行,目前活動接受上一項活動的工作結果,實施完成所需的工作内容。目前活動的工作結果需要進行驗證,如果驗證通過,則該結果作為下一項活動的輸入,繼續進行下一項活動,否則傳回修改。
瀑布模型強調文檔的作用,并要求每個階段都要仔細驗證。但是,這種模型的線性過程太理想化,已不再适合現代的軟體開發模式,幾乎被業界抛棄,其主要問題在于:
(1) 各個階段的劃分完全固定,階段之間産生大量的文檔,極大地增加了工作量。
(2) 由于開發模型是線性的,使用者隻有等到整個過程的末期才能見到開發成果,進而增加了開發的風險。
(3) 早期的錯誤可能要等到開發後期的測試階段才能發現,進而帶來嚴重的後果。
按照瀑布模型的階段劃分,軟體測試可以分為單元測試,內建測試,系統測試。
(俗語)需求分析:把使用者的需求以及界面所使用的功能展示出來
使用者要怎麼用顯示出來
概要設計:總體設計 接口設計 資料結構設計 運作設計 出錯設計
大緻的設計展示出來
詳細設計:各個軟體子產品詳細的劃分 功能概述 界面概述 類設計 關系邏輯與算法說明 通路的表或其他資料庫實體 調用外部接口說明 提供調用接口說明 子產品内部使用的公用函數/包等的說明
軟體開發瀑布模型
需求規格說明書
概要設計說明書