三個模型

1. 瀑布模型
2. 增量模型
3. 集成和配置模型

沒有適用于所有不同類型軟件開發的過程模型。

瀑布模型

• 需求定義
• 系統和軟件的設計
• 實現與單元測試
• 集成與系統測試
• 運行與維護

瀑布模型的特征

1. 從上一項活動中接受該項活動的工作成果（工作產品），作為輸入。
2. 利用這一輸入實施該項活動應完成的內容
3. 給出該項活動的工作成果，作為輸出傳給下一項活動
4. 對該項活動實施的工作進行評審。若其工作得到確認，則繼續下一項活動。

瀑布模型的優點：

1.強調開發的階段性；
2.強調早期計劃及需求調查；
3.強調產品測試。

瀑布模型的缺點：

• 從認識論角度看，人的認識是一個多次反復循環的過程，不可能一次完成。但瀑布模型中劃分的幾個階段，沒有反映出這種認識過程的反復性。 特別是瀑布模型過于依賴早期進行的唯一一次需求調查，不能適應需求的變化；
• 軟件開發是一個知識密集型的開發活動，需要相互合作完成，但瀑布模型沒有體現這一點。特別是由于瀑布模型是單一流程，開發中的經驗教訓不能反饋應用于本產品的過程。

瀑布模型適合的系統種類

• 嵌入式系統：軟件必須和硬件連接、交互，由于硬件不靈活，將軟件功能的決策推遲到開發階段通常不可行。
• 關鍵性系統：要求在早期對軟件規格說明和設計的安全性和信息安全進行全面分析，在實現階段處理安全性問題通常代價非常大。
• 大型軟件系統：需要完整的規格說明以使不同的子系統可以獨立開發。

增量模型

增量模型的特點

• 增量模型又稱產品改進模型（Incremental Model）
• 從給定需求開始，通過構造一系列中間版本來實施開發活動，依次類推，直到系統完成。
• 每一個中間版本都是需求分析、設計、編碼和測試的過程。
• 某些中間版本的開發可以并行進行。

增量模型的優點

1. 降低了實現需求變更的成本。較瀑布模型而言，重新分析和修改文檔的工作流要少很多。
2. 在開發過程中更容易得到客戶對已完成的開發工作的反饋意見。客戶可以對軟件的已有版本進行評價，并可以判斷項目進度；客戶通常會覺得從軟件設計文檔中評價項目、判斷項目進度很困難。
3. 即使并未實現所有功能，也可以在早期向客戶交付有用的軟件，相對瀑布模型而言，客戶可以更早地使用軟件

增量模型的缺點

1. 過程不可見。管理人員需要常規的交付物來掌握進度。如果系統是快速開發的，那么要產生每個版本的文檔就很不劃算。
2. 伴隨新的增量的加入，系統結構會退化。敏捷方法建議定期對軟件重構。
3. 面對大型、復雜以及長生命周期的系統，增量模型的以上缺點更為突出。大型系統不同部分由不同團隊開發，需要穩定的框架或體系結構，這種體系結構需要事先進行計劃而不是增量地開發。

集成與配置模型

尋找可復用的代碼，按照需求對他們進行修改，并將他們與新代碼相集成。

優點與缺點

優點：

• 基于配置和集成的面向復用的軟件工程在降低軟件開發量以及降低成本和風險方面有著明顯的優勢。
• 可以實現更快的軟件交付。

缺點：

• 系統可能不完全滿足用戶的真實需求。
• 可能失去對系統演化的控制，因為可復用構建的新版本并不在使用該構件的組織的控制之下。

軟件過程

軟件過程中的四個活動(牢記)

1. 軟件需求規格說明（可行性分析、需求獲取、需求分析）
2. 軟件開發（總體設計、詳細設計、實現）
3. 軟件確認（測試）
4. 軟件演化（維護）

應對變化(牢記)

1. 變化預測：軟件過程包括可以在要求大量返工之前預見或預測可能的變化的活動，如原型。
2. 變化容忍：基于過程和軟件設計手段，使系統修改變得容易。如增量模型、重構、框架。

過程改進的方法

1. 過程成熟度方法。關注改進過程和項目管理，并將好的軟件工程實踐引入到組織中。目標是提高產品質量和過程的可預測性。
2. 敏捷方法。關注迭代化的開發以及降低軟件工程中的額外開銷。主要特點是快速交付功能以及對客戶需求變更的快速響應。其哲學思想：最好的過程是那些額外開銷最低的過程。

過程成熟度方法：

CMM是指“能力成熟度模型"其英文全稱為Capability Maturity Model for Software，英文縮寫為SW-CMM，簡稱CMM。
正式的過程改進中的額外開銷過高，小企業不用，有些大企業在實踐。

如何選擇軟件過程模型

1. 在前期需求明確的情況下盡量采用瀑布模型或改進型的瀑布模型.
2. 在用戶無信息系統使用經驗,需求分析人員技能不足情況下一定要借助原型.
3. 在不確定性因素很多,很多東西前面無法計劃情況下盡量采用RUP和螺旋模型
4. 在需求不穩定情況下盡量采用RUP模型
5. 在資金和成本無法一次到位情況下可以采用增量模型,軟件產品分多個版本進行發布
6. 對于完全多個獨立功能開發可以在需求階段就分功能并行,但每個功能內都應該遵循瀑布模型
7. 對于全新系統的開發必須在總體設計完成后再開始增量或并行.
8. 對于編碼人員經驗較少情況下建議不要采用敏捷或迭代等生命周期模型.
9. 增量,迭代和原型可以綜合使用,但每一次增量或迭代都必須有明確的交付和出口準則.