文章目錄

• • 1.前言
  • 2.瀑布模型--按階段嚴格完成
  • • （1）瀑布模型把整個項目過程分成了六個主要階段：
    • （2）舉個例子來理解瀑布模型
    • （3）優缺點
    • （4）解決的重要問題
  • 3.快速原型模型--低成本快速的確認需求
  • • （1）類比介紹
    • （2）拋棄策略
    • （3）附加策略
    • （4）原型設計工具
  • 4.增量模型--按模塊分批次交付
  • • （1）類比介紹
    • （2）適用場景
  • 5.迭代模型——每次迭代都有一個可用的版本
  • 6.增量模型與迭代模型的區分
  • 7.我該選擇什么過程模型？
  • • 場景一：外包項目，需要階段驗收
    • 場景二：項目風險高，隨時可能會中斷---螺旋模型
    • 場景三：山寨一款軟件產品，希望能快速上線發布
    • 場景四：客戶都沒想清楚想要什么，但是個大單子
    • 場景五：我的產品已經上線，但是需要持續更新維護
  • 8.總結

---

1.前言

我們說軟件工程=過程+工具+方法；
那么本節內容就聊一聊過程,即軟件從無到有的一個過程，它有很多種方法，這些方法被稱為一個又一個模型。這些常見模型有：瀑布模型、快速原型開發模型、增量模型、迭代模型、螺旋模型，還有敏捷模型，由于篇幅較長，下一篇筆記再總結。

2.瀑布模型–按階段嚴格完成

• 可以這么說：瀑布模型算是現代軟件工程的起源，軟件工程的發展，很大部分都是構建于瀑布模型的基礎之上的·。軟件工程的很多內容，都是源自瀑布模型的衍生，或者其中某個階段的細分。

（1）瀑布模型把整個項目過程分成了六個主要階段：

一、問題的定義及規劃
這個階段是需求方和開發方共同確定軟件開發目標，同時還要做可行性研究，以確定項目可行。這個階段會產生需求文檔和可行性研究報告。

二、需求分析
對需求方提出的所有需求，進行詳細的分析。這個階段一般需要和客戶反復確認，以保證能充分理解客戶需求。最終會形成需求分析文檔。

三、軟件設計
根據需求分析的結果，對整個軟件系統進行抽象和設計，如系統框架設計，數據庫設計等等。最后會形成架構設計文檔。

四、程序編碼
將架構設計和界面設計的結果轉換成計算機能運行的程序代碼。

五、軟件測試
在編碼完成后，對可運行的結果對照需求分析文檔進行嚴密的測試。如果測試發現問題，需要修復。最終測試完成后，形成測試報告。

六、運行維護
在軟件開發完成，正式運行投入使用。后續需要繼續維護，修復錯誤和增加功能。交付時需要提供使用說明文檔。

• 瀑布模型在提出后，因為其簡單可行，切實有效，馬上就在很多軟件項目中應用起來，一直到 2000 年前后，都是最主流的軟件開發模型，即使到現在，你也能在很多軟件項目中看到它的影子。

軟件生命周期：軟件生命周期是軟件的產生直到報廢或停止使用的生命周期。而像瀑布模型這樣，通過把整個軟件生命周期劃分為若干階段來管理軟件開發過程的方法，叫軟件生命周期模型。

• 雖然現在瀑布模型已經不是最主流的開發模式，那為什么我們現在還要學習瀑布模型呢？

• 因為不管什么軟件項目，不管采用什么開發模式，有四種活動是必不可少的，那就是·需求、設計、編碼和測試。而這四項活動，都是起源自瀑布模型，也是瀑布模型中核心的部分。

（2）舉個例子來理解瀑布模型

我們拿蓋房子的過程來看看瀑布模型。

• 客戶想要蓋一棟房子（初步的想法）。
• 客戶一開始可能沒想清楚想要什么樣子的房子。（客戶對需求還不清楚）
• 施工方開始找客戶確認：用途是什么，要個幾層的房子，什么建筑風格，希望什么時間完工，預算多少。（問題定義）
• 施工方根據客戶提的需求，對比工期和預算，評估是不是值得做。（可行性研究）
• 施工方評估后覺得可行，于是和客戶簽訂合同，約定價錢和工期。（立項，制定項目計劃）
• 施工方開始跟客戶溝通確認需求，例如每層戶型如何，將來的裝修風格等。（需求分析）
• 確認完需求后，施工方開始出建筑施工圖，還畫了漂亮的建筑效果圖。（系統設計和 UI 設計）
  施工方按照設計圖開始施工。（程序編碼）
• 這期間如果客戶去參觀施工情況，客戶只能看到毛胚，只有最后施工完成才能看到最終樣子。（在中間客戶看不到結果，只有最后能看到結果）
• 原定二層是兩個臥室，在房子施工過程中，突然客戶說兩個臥室不夠，要改成三個臥室。這意味著施工方要對施工圖重新設計，很多已經建好的房間要拆掉重建。（瀑布模型是很難響應需求變更的，而且越到后期代價越大）
• 工程質量檢查人員對施工結果進行質量檢測，如果不滿足質量要求，需要修改。（測試）
• 最后驗收通過后，客戶入住。（上線）

（3）優缺點

（4）解決的重要問題

瀑布模型的出現，也解決了軟件項目開發中的幾個重要問題。

• 讓軟件開發過程有序可控。瀑布模型的每個階段都有明確的任務，每個階段都有明確的交付產物，都有相應的里程碑。這些讓整個過程更可控，而且能及早發現問題。
• 讓分工協作變成可能。瀑布模型的六個階段，也讓軟件開發產生相應的基礎分工：項目經理、產品經理、架構師、軟件工程師、測試工程師、運維工程師。
• 質量有保障。瀑布模型每個階段都需要交付相應的文檔，而文檔的撰寫和評審，可以幫助在動手之前把問題溝通清楚，想清楚。瀑布模型在編碼結束后，會有嚴密的測試，只有測試驗收通過后，才能上線發布。這些措施都讓軟件的質量更有保障。

3.快速原型模型–低成本快速的確認需求

（1）類比介紹

• 快速原型模型，就是為了要解決客戶的需求不明確和需求多變的問題。用于低成本快速的確認需求,沒必要花太長時間在代碼質量上，趕緊做出來才是王道

• 先迅速建造一個可以運行的軟件原型，然后收集用戶反饋，再反復修改確認，使開發出的軟件能真正反映用戶需求，這種開發模型就叫快速原型模型，也叫原型模型。

• 這就好比客戶想要蓋房子，但是他沒想好要蓋成什么樣子，于是施工方就先搭了一棟彩鋼房（就像工地里面搭的臨時房子），讓客戶先用起來，然后再給反饋調整。

• 因為彩鋼房搭建簡單快速，改起來也相對容易。等到客戶確定好需求，再在已經搭好的彩鋼房的基礎上完善，或者直接重新按照確定好的需求造房子。

• 不過，這樣做也有一個問題，用彩鋼房這種方式蓋房子雖然快，但是 房子質量不會太好，住的不算舒服，想有點個性化的風格也難。

• 同樣的道理，也適用于軟件項目。彩鋼房就像是軟件原型，重點是反映軟件核心功能和交互，功能可以是不完整的，可靠性和性能要求不高，但開發速度可以很快。

• 原型模型因為能快速修改，所以能快速對用戶的反饋和變更作出響應，同時原型模型注重和客戶的溝通，所以最終開發出來的軟件能夠真正反映用戶的需求。

• 但這種快速原型開發往往是以犧牲質量為代價的。

• 在原型開發過程中，沒有經過嚴謹的系統設計和規劃，可靠性和性能都難以保障。所以在實際的軟件項目中，針對原型模型的這種快速、低質量的特點，通常有兩種處理策略：拋棄策略和附加策略。

（2）拋棄策略

• 拋棄策略是將原型只應用于需求分析階段，在確認完需求后，原型會被拋棄，實際開發時，將重新開發所有功能。類似于用彩鋼房蓋房子，確認完客戶需求后，拆掉重新建。

（3）附加策略

• 附加策略則是將原型應用于整個開發過程，原型一直在完善，不斷增加新功能新需求，直到滿足客戶所有需求，最終將原型變成交付客戶的軟件。類似于用彩鋼房蓋房子，最后還要做一番精裝修，交付客戶。

采用哪種策略來應用原型模型，還是要看項目特點，包括所采用原型開發工具和技術的成熟度。舉例來說，如果客戶對可靠性、性能要求高，那么就最好是拋棄策略，如果客戶對質量要求不高，有簡單功能就夠了，那么可以試試附加策略。

（4）原型設計工具

• 原型制作并不一定要像傳統代碼一樣進行設計編碼，有很多原型工具，像 Axure、墨刀等，簡單的拖拽就可以實現簡單的界面和交互，同樣可以達到確認需求的目的。

瀑布模型的很多問題，根源都是周期太長。周期長所以中間難以響應變更，周期長所以客戶很久才能看到結果，周期太長所以風險不好控制。如果能將周期變短，那么很多問題就迎刃而解了
基于這種思路，產生了很多開發模型，比較典型的主要是：·增量模型 和 迭代模型·。

4.增量模型–按模塊分批次交付

（1）類比介紹

• 增量模型是把待開發的軟件系統模塊化，然后在每個小模塊的開發過程中，應用一個小瀑布模型，對這個模塊進行需求分析、設計、編碼和測試。相對瀑布模型而言，增量模型周期更短，不需要一次性把整個軟件產品交付給客戶，而是分批次交付。

• 如果拿蓋房子來比喻的話，就是先蓋衛生間，然后蓋廚房，再是臥室。

• 蓋衛生間的時候，也要先分析需求，然后設計，再實施，最后驗收。有時候也可以多模塊并行，例如同時蓋衛生間和廚房，前提是模塊之間不能有依賴關系，比如，你不可能先蓋二樓再蓋一樓。

• 因為增量模型的根基是模塊化，所以，如果系統不能模塊化，那么將很難采用增量模型的模式來開發。另外，對模塊的劃分很抽象，這本身對于系統架構的水平是要求很高的。

（2）適用場景

• 基于這樣的特點，增量模型主要適用于：需求比較清楚，能模塊化的軟件系統，并且可以按模塊分批次交付。

5.迭代模型——每次迭代都有一個可用的版本

• 迭代模型每次只設計和實現產品的一部分，然后逐步完成更多功能。

• 每次設計和實現一個階段叫做一個迭代。

• 我們還是繼續拿蓋房子來舉例：如果用迭代模型的方式蓋房子，第一個迭代要先蓋一個茅草屋，快速滿足客戶對房子的核心需求；第二個迭代再蓋一個小木屋，比茅草房更大更舒適；第三個迭代再蓋成一個豪華別墅，滿足客戶所有需求。

• 你要注意，無論是造小木屋還是大別墅，整個過程都會像一個完整的項目一樣，包括需求分析、設計、實現與測試驗收。

• 在迭代模型中，整個項目被拆分成一系列小的迭代。通常一個迭代的時間都是固定的，不會太長，例如 2-4 周。每次迭代只實現一部分功能，做能在這個周期內完成的功能。

• 在一個迭代中都會包括·需求分析、設計、實現和測試，類似于一個小瀑布模型。迭代結束時要完成一個可以運行的交付版本。
  

6.增量模型與迭代模型的區分

• 增量模型是按照功能模塊來拆分；而迭代模型則是按照時間來拆分，看單位時間內能完成多少功能。

• 還是用蓋房子來理解，增量模型則是先蓋廚房，再是臥室，這樣一個個模塊來完成。

• 而迭代模型則是先蓋一個簡單的茅草房，有簡易的土灶和土床，然后再升級成小木屋，有更好的灶和更好的臥室，這樣一步步迭代成最終的房子。

7.我該選擇什么過程模型？

場景一：外包項目，需要階段驗收

假如你現在是一家外包公司，你可以采用瀑布模型開發，但是甲方需要對你項目的每個階段進行驗收測試，以確認你是不是達到要求。

針對從需求定義一直到編碼階段，每個階段都有對應的測試驗收。如果畫成圖，就是下面這個樣子的。

這個模型就是V 模型，本質上它還是瀑布模型，只不過它是更重視對每個階段驗收測試的過程模型。

場景二：項目風險高，隨時可能會中斷—螺旋模型

如果你現在要做一個風險很高的項目，客戶可能隨時不給你錢了。這種情況下，如果采用傳統瀑布模型，無疑風險很高，可能做完的時候才發現客戶給不了錢，損失就很大了！

這種情況，基于增量模型或者迭代模型進行開發，就可以有效降低風險。你需要注意的是，在每次交付的時候，要同時做一個風險評估，如果風險過大就不繼續后續開發了，及時止損。

這種強調風險，以風險驅動的方式完善項目的開發模型就是·螺旋模型·。

場景三：山寨一款軟件產品，希望能快速上線發布

• 其實軟件行業山寨的案例不少，山寨項目的特點是，項目需求是明確的，不會有什么變化，這時候就可以選擇·增量模型，劃分好模塊，先實現核心模塊，發布可運行版本，再增量發布其他模塊。多模塊可以同步開發。

場景四：客戶都沒想清楚想要什么，但是個大單子

• 很多項目，客戶一開始都沒想清楚想要的是什么，需要花很長時間去分析定義需求，但是單子很大，值得認真去做好。

• 那么這樣的項目，你可以考慮拆分成四個階段：

初始階段

• 主要是確定需求邊界和主要風險，幾乎沒有什么開發工作。

細化階段

• 這個階段主要是確定需求，可以采用快速原型模型開發，和客戶對需求反復確認，需要輔助一定量的開發和測試工作。對代碼質量可以要求比較低，重點是確認需求。可能需要一個或多個版本迭代。

構造階段

• 在需求確認清楚后，現在可以使用迭代模型來開發，逐步交付產品。這個階段的重點是開發和測試。如果迭代中，有新的需求加入或者需求變更，也可以在新的迭代中加入。

交付階段

• 在開發和測試完成后，產品可以交付客戶，根據線上運行情況還需要修復一些 Bug。這個階段重點是測試和部署。也會有多個迭代。

• 整個過程看起來就像下圖這樣。
  
  上面這種開發方式來源自·統一軟件開發過程（Rational Unified Process，RUP），適用于復雜和需求不明確的軟件系統。·

場景五：我的產品已經上線，但是需要持續更新維護

• 很多產品在上線后，還在保持不停的更新維護，修復 Bug、增加新功能，每個月甚至每周更新。

• 在這種情況下，·迭代模型·是比較合適的。固定時間周期，在固定的周期內選擇適合的需求開發任務和 Bug 修復任務去完成，按時發布。

• 另外還可以嘗試敏捷開發，也是基于迭代的開發模型，它也強調快速交付，每次交付系統的部分功能，來保證客戶滿意度。

8.總結

• 現在的軟件項目，各種類型都有，根據項目特點，選擇好合適的開發模型，可以讓你事半功倍，降低項目風險，提高項目開發效率，控制項目成本。比如說：

• 一個以確認需求為主要目的的項目，就可以不用花太多時間在代碼質量上面，低成本、高效做出來才是最重要的；

• 一個高風險的項目，則可以采用螺旋模型，出現問題及時止損；

• 一個很長時間加班加點，卻一直沒法上線，導致士氣低落的項目，可以改成增量模型，先上線一個小模塊，讓大家看到成績提升士氣，然后再迭代，逐步上線其他模塊。

• 同時，你也不必拘泥于這幾種開發模型，還可以借鑒其他模型做的好的地方，甚至創造自己的開發模型，比如說你覺得敏捷的“站立會議”適合你的項目，那也可以借鑒過來。

參考：極客時間–軟件工程之美

總結

以上是生活随笔為你收集整理的104. 软件工程的开发过程几种模型（瀑布模型、快速原型开发模型、增量模型、迭代模型、螺旋模型）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。