淺談軟體開發模型之瀑布開發和敏捷開發

學習中的苦與樂發表於2021-04-19

 

 

 

 

 1、瀑布模型

1.1 瀑布模型的特點

      1970年溫斯頓·羅伊斯(Winston Royce)提出了著名的“瀑布模型”,直到80年代早期,它一直是唯一被廣泛採用的軟體開發模型。

  

 

 

1.2 瀑布模型核心思想

      瀑布模型核心思想是按工序將問題化簡,將功能的實現與設計分開,便於分工協作,即採用結構化的分析與設計方法將邏輯實現與物理實現分開。

將軟體生命週期劃分為制定計劃、需求分析、軟體設計、程式編寫、軟體測試和執行維護等六個基本活動,

並且規定了它們自上而下、相互銜接的固定次序,如同瀑布流水,逐級下落。

 

1.3 瀑布模型顯著特點

1.嚴格把軟體專案的開發分隔成各個開發階段:需求分析,要件定義,基本設計,詳細設計,編碼,單體測試,結合測試,系統測試等。

使用里程碑的方式,嚴格定義了各開發階段的輸入和輸出。如果達不到要求的輸出,下一階段的工作就不展開。

 

2.重視和強調過程文件,在開發的中後期才會看到軟體原型,早期只能通過文件來了解系統的模樣。

在這種情況下,文件的重要性彷彿已經超過了程式碼的重要性。

 

3.瀑布模型把每個開發階段都定義為黑盒,希望每個階段的人員只關心自己階段的工作,不需要關注其他階段的工作。

好處是:可以讓開發人員能夠更專注於本職工作,提高階段效率。

壞處是:

  • a.由於各階段的開發人員只能接觸到自己工作範圍內的東西,所以對客戶需求的理解程度高低不等,開發人員更像是定義為流水線上的工人。
  • b.對於客戶需求變更,編碼人員會比設計人員更容易產生很強的牴觸情緒。
  • c.在每個開發階段都會有一些資訊刻意的不讓其他開發階段的人員知道(本意是為了提到效率,但實際上有時候產生的是互相的理解偏差)。

 

4.瀑布模型產生的管理文件(計劃書,進度表)等,能讓不太瞭解該專案的人也能看懂專案的進度情況(只有能看懂百分比就行),很適合向領導彙報用。

所以管理人員比較喜歡瀑布模型,但是開發人員不喜歡,因為它束縛了開發人員的創造性。

 

5.既然叫做瀑布,就意味著不應該走回頭路。否則如果出現返工,付出的代價會很大。

軟體生命週期前期造成的Bug的影響比後期的大的多。

代價比較大的主要原因還是每個開發階段的步子過大,每一次調整都可能傷筋動骨。

 

6.更適合需求相對穩定的大型專案。

1.4 瀑布模型不足之處

  1.   在專案各個階段之間極少有反饋。
  2.   只有在專案生命週期的後期才能看到結果。
  3.   通過過多的強制完成日期和里程碑來跟蹤各個專案階段。
  4.   瀑布模型的突出缺點是不適應使用者需求的變化。

 

 


2、敏捷開發

 是一種從1990年代開始逐漸引起廣泛關注的一些新型軟體開發方法,是一種應對快速變化的需求的一種軟體開發能力。

相對於“非敏捷”,更強調程式設計師團隊與業務專家之間的緊密協作、面對面的溝通(認為比書面的文件更有效)、頻繁交付新的軟體版本。

能夠很好地適應需求變化的程式碼編寫和團隊組織方法,也更注重軟體開發中人的作用。

敏捷建模(Agile Modeling,AM)的價值觀包括了XP的四個價值觀:溝通、簡單、反饋、勇氣,此外,還擴充套件了第五個價值觀:謙遜。

 

 

 

2.1 敏捷開發特點

極限程式設計的思想體現了適應客戶需求的快速變化,激發開發者的熱情,也是目前敏捷開發思維的重要支持者。

敏捷軟體開發是一個開發軟體的管理新模式,用來替代以檔案驅動開發的瀑布開發模式。

敏捷開發整合了新型開發模式的共同特點

  1. 敏捷就是“快”。快才可以適應目前社會的快節奏,要快就要發揮個人的個性思維多一些個性思維的增多。
  2. 客戶參與。以人為本,客戶是軟體的使用者,是業務理解的專家,沒有客戶的參與,開發者很難理解客戶的真實需求。
  3. 強調軟體開發的產品是軟體,而不是文件。文件是為軟體開發服務的,而不是開發的主體。
  4. 設計周密是為了最終軟體的質量,但不表明設計比實現更重要
  5. 迭代。軟體的功能是客戶的需求,介面的操作是客戶的“感覺”。對迭代的強調是縮短了軟體版本的週期。
  6. 小版本。快速功能的展現,看似簡單,但對於複雜的客戶需求合理地分割與總體上的統一,要很好地二者兼顧是不容易的。

 

(1)人和互動 重於過程和工具。 

(2)可以工作的軟體 重於求全而完備的文件。 

(3)客戶協作重於合同談判。  

(4)隨時應對變化重於循規蹈矩。  

  專案的敏捷開發,敏捷開發小組主要的工作方式可以歸納為:

  • 作為一個整體工作; 
  • 按短迭代週期工作; 
  • 每次迭代交付一些成果:關注業務優先順序; 
  • 檢查與調整。  

最重要的因素恐怕是專案的規模,規模增長,面對面的溝通就愈加困難, 因此敏捷方法更適用於較小的隊伍,40、30、20、10人或者更少。

 

 

歡迎關注訂閱微信公眾號【熊澤有話說】,更多好玩易學知識等你來取
作者:熊澤-學習中的苦與樂
公眾號:熊澤有話說
出處: https://www.cnblogs.com/xiongze520/p/14676958.html
創作不易,任何人或團體、機構全部轉載或者部分轉載、摘錄,請在文章明顯位置註明作者和原文連結。  

 

相關文章