軟件工程學習5-瀑布模型總結


1 瀑布模型怎么來的?

(1)所謂軟件危機

瀑布模型算是現代軟件工程的起源,軟件工程的發展,很大部分都是構建於瀑布模型的基礎之上的。在校期間做的項目相對簡單,通常不會涉及到諸如性能測試等,通常為邊寫邊改,但是一旦

項目變復雜,開發人員水平參差不齊,從而導致軟件開發與維護過程中出現一系列嚴重問題,這個現象也被稱之為“軟件危機”。

(2)邊寫邊改的缺點

  • 開發的過程不可控
  • 項目的人數多了以后,不方便協作分工
  • 對需求分析的理解誤差,導致返工,從而影響項目交付
  • 沒有有效的測試,上線問題一堆

(3)瀑布模型的誕生

  1970 年,Winston Royce 博士借鑒了其他工程領域的思想,比如建築工程,提出了瀑布開發模型,指出軟件開發應有完整之周期,並將軟件開發過程分成了若干階段。像瀑布一樣,從上往下,完成一個階段繼續下一個階段

 

 

 2 瀑布模型案例

按照一個我曾經畢業設計的案例

(1) 項目的定義和規划

  畢業設計是做一個c++的網絡嗅探器,所用庫為libpcap,可行性沒問題,老師大概給我說了下需要做哪些功能,然后說兩個月完成吧。啊,你怕是在開玩笑,當時讀本科一天天都是在摸魚。。初步定下時間吧

       需求分析——1 周;
  軟件設計——1周;
  程序編碼——4 周;
  軟件測試——1周。

的確如此,軟件測試在當時開來就是功能測試,實現功能就完事,哎!!!

(2) 需求分析階段

  通過查看論文文獻,使用viso畫了一個項目的結構圖,然后去和老師討論,然后加了一些需求,並需要形成文檔,然后再和老師談論,最終確定了需求的文檔,現在的時間變成這個樣子。

       需求分析——2周
  軟件設計——1周;
  程序編碼——3 周;
  軟件測試——1周。

       需求階段多花了一周時間,這樣子程序的編碼就被壓縮了一周,因為需要在規定的時間盡量完成任務嘛,畢業要緊!!

(3) 軟件的設計

  這個時候,老師就對應公司里面的架構師角色,畫了一個圖說明采用什么架構,用什么來界面展示,數據庫采用什么。差不多就確定了,但是我寫了差不多一周代碼后,老師問我進展,需要我加上一些數據包統計功能等

這樣子前前后后,軟件的設計花了兩周的時間。

     需求分析——2周;
  軟件設計——2周
  程序編碼——2 周
  軟件測試——1周。

(4)編碼

  有了文檔,開始編碼,時間壓縮了很多,加班呀,使勁加班!!但是身體受不了,只好問老師能不能往后延遲兩周,編碼,調試,有時候老師還要加功能,前前后后差不多花了4周時間。這樣子相當於項目延期2周。

  需求分析——2周;
  軟件設計——2周;
  程序編碼——4周
  軟件測試——1周。

(5)測試

  前期需求多了一周,軟件設計多花了一周,在既定的時間里,只能壓縮編碼和測試的時間,加班!!

綜上可知,這樣子分層的思想,的確可以在每一步的實施上面可以效率比較高,這種編碼前先設計、編碼后測試、整個過程重視文檔的方式,開發出來的產品,質量相對是有保障的。但是一旦前面某個環節出了問題,返工的操作不是延期就是壓縮編碼測試的時間。從而成了9116.。。。。。

3 瀑布模型的優缺點

  最大的問題就是不能及時響應需求變更,越到后期變更代價越大

優點

  • 簡單易行
  • 可以進行階段檢查,能夠及時發現問題
  • 較好的分工協作,不同階段不同職位,架構師,項目經理,開發工程師,測試工程師,運維工程師
  • 對質量有一定的保障,因為每個階段有詳細的文檔

缺點

  • 難以響應需求的變更
  • 工作量分配不均勻
  • 前期階段受阻壓縮后期進展

4 總結

  瀑布模型的出現,也解決了軟件項目開發中的幾個重要問題。進行了模塊划分,各個階段負責各個階段的內容,所謂分工明確。質量有了保證,每個階段都有相應的文檔評審,可以幫助大家少走彎路,提高工作效率。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM