1、定義
軟件過程也稱為軟件生存周期過程，是指軟件生存周期中的一系列相關過程。 為了獲得高質量軟件所需要完成的一系列任務的框架，它規定了完成各項任務的工作步驟。

2、軟件過程的七大元素
活動：開發、維護、管理等；
任務：活動的細分，確定、安排任務等；
工件：軟件過程的工作產品，分輸入與輸出工件；
角色：定義了軟件過程中的個人或小組的行為與職責；
資源：最佳實踐、工具、技術、機器、場地等；
目標：每個過程有明確的目標；
度量指標：目標的具體度量與分析，如進度、成本、質量、返工率。

3、軟件生存周期模型
又稱軟件開發模型，是軟件生命周期的一個框架，規定了軟件開發、運作和維護等所需的過程、活動和任務。

4、軟件生存周期模型分類
線性順序模型 Waterfall Model
增量式模型 Incremental Model
演化模型 Evolutionary Model

5、線性順序模型
瀑布模型，又稱線性順序模型
需求分析->設計->實現->測試->交付->使用和維護
特點：
強調階段的劃分順序與依賴；
強調各階段工作文檔的完備性，即文檔驅動靜態描述；
每個階段從技術和管理進行嚴格的審查，即質量保證的觀點；
是一種線性的、順序的、逐步細化的開發模式；
推遲實現的觀點；
適用時機：
所有功能、性能等要求能一次理解和描述時
所有的系統功能一次交付時
必須同時淘汰全部老系統時
實際的瀑布模型特點：
具有反饋環
價值：

• 結構簡單明了；歷史較長、應用面廣泛、為廣大軟件工作者所熟悉；已有與之配套的一組十分成熟的開發方法和豐富的支撐工具。
• 一種較為有效的管理模式：訂計劃、成本預算、組織開發人員,階段評審,文檔管理,從而對軟件質量有一定的保證。

風險和缺點：
獲得完善的需求規約是非常困難的；
難以適應快速變化需求；
系統太大時,難以一次做完；
反饋信息慢；
極可能引起開發后期的大量返工，如返工到需求、設計等早期活動；

建議不要使用該模型的幾種情況：

• 需求未被充分理解
• 系統太大而不能一次開發完成
• 事先打算采用的技術迅速發生變化
• 需求迅速發生變化
• 資源有限，如現有的工作人員/資金不足。
• 無法利用某一中間產品

6、增量模型
軟件被分解成許多增量構件，逐個提交。
構造一系列可執行的中間版本(Version by Version)

適用時機
需要早期獲得功能；
中間產品可以提供使用；
系統被自然地分割成增量；
工作人員/資金可以逐步增加。

需考慮的風險
需求未被很好地理解
一次要求所有功能
需求迅速發生變化
事先打算采用的技術迅速發生變化
長時期內僅有有限的資源（人員/資金）

7、演化模型
只要核心需求能夠被很好地理解，就可以進行漸進式開發，其余需求可以在后續的迭代中進一步定義和實現。這種過程模型稱為演化模型，它能很好地適應隨時間演化的產品的開發。

特點：
迭代的開發方法，漸進地開發各個可執行版本，逐步完善軟件產品。每個版本在開發時，開發過程中的活動和任務順序地或部分重疊平行地被采用。

與增量模型的區別：
需求在開發早期不能被完全了解和確定，在一部分被定義后開發就開始了，然后在每個相繼的版本中逐步完善。

演化模型在理解了核心需求就可以進行漸進開發，首先執行風險最大的任務，漸進迭代開發各個可執行的版本，允許需求變更。

現代軟件過程都采用演化模型：
統一軟件過程RUP
敏捷過程 （SCRUM、XP等）
凈室（Cleanroom）軟件過程

演化模型的“子類”
原型 Prototyping
螺旋模型 Spiral Model
并發開發模型 Concurrent Development Model

（1）迭代化開發
特點：盡可能降低風險，適用處理不確定的復雜系統。
原則:
1、每次迭代產生一個可執行的版本；
2、要求有計劃地迭代。
選擇功能，上一個迭代的結果，新的風險評估結果，模型、代碼和測試的受控庫->迭代規劃->需求獲取->分析與設計->實現->測試->準備發布->發布，更新的風險評估，受控庫

（2）快速原型模型
特點：
定義出總體目標或初步需求就開發原型，通過原型與用戶交互識別進一步的需求.
（1）拋棄式原型
（2）演化式原型
需求分析->原型開發->原型評價->最終系統設計->最終系統實現。

（3）螺旋模型

8、RUP（Rational Unified Process）統一軟件過程
RUP蘊涵了最佳實踐準則
（1）迭代式開發
（2）管理需求
（3）使用基于構件的體系結構
（4）可視化建模
（5）貫穿于開發過程的軟件質量驗證
（6）控制軟件變更
RUP是一個風險驅動的、基于UML和構件式架構的迭代、遞增型開發過程 。

Inception(初始)
目的:在所有項目干系人之間就項目目標達成共識
Elaboration(精化)
目的:建立架構基線,解決技術風險,為設計與實現奠定基礎
Construction(構建)
目的:完成系統開發
Transition(產品化)
目的:確保最終用戶可以使用

6個核心規范和3個支持規范、
核心規范:
業務建模(系統目標達成共識)
需求(系統范圍達成共識)
設計
實現
測試
部署
支持規范:
配置與變更管理
項目管理(風險,計劃,進度等)
環境

9、敏捷過程
敏捷過程：具有高效、快速響應變化的開發過程。
層次：
動機->價值->原則->實踐做法
動機：
快速的市場進入時間、快速變化的需求、快速發展的技術。

價值-敏捷宣言：
（1）個體和交互勝過過程和工具；
（2）可以工作的軟件勝過面面俱到的文檔；
（3）客戶合作勝過合同談判；
（4）響應變化勝過遵循計劃。

敏捷過程的原則：
優先目標是盡早持續交付高價值的軟件來滿足客戶需求；
通過駕馭變化幫助客戶贏得競爭；
經常交付可用軟件；
業務員和開發人員必須每天一起工作；
以積極主動地人為核心建立項目團隊；
可用軟件是最主要的項目進展目標；
團隊內外最有效的交流是面對面交流；
提倡可持續開發，保持穩定的工作步調；
用精益求精和優良設計增強敏捷性；
簡約—工作最小化；
最優的架構、需求和設計來自自組織的團隊；
團隊不斷開展工作反思，校正自身行為。

適用于敏捷過程的情況：
需求不確定、易揮發
有責任感和積極向上的開發人員
用戶容易溝通并能參與
小于10個人的項目團隊

10、極限編程
極限編程是敏捷過程中最著名的一種，指把好的開發實踐運用到極致，多應用于軟件需求模糊的場合。

價值觀：
溝通、反饋、簡化、勇氣

特點：
測試成為開發的核心;
紀律性與靈活性巧妙結合.

XP關鍵做法：
現場客戶（On-site Customer）
計劃博弈（Planning Game）
系統隱喻（System Metaphor）
簡化設計（Simple Design）
集體擁有代碼（Collective Code Ownership）
結對編程（Pair Programming）
測試驅動（Test-driven）
小型發布（Small Releases）
重構（Refactoring）
持續集成（Continuous integration）
每周40小時工作制（40-hour Weeks）
代碼規范（Coding Standards）

11、RUP與XP的共性
基礎都是面向對象方法（取代傳統的結構化方法）
都重視代碼、文檔的最小化和設計的簡化
采用動態適應變化的演進式迭代周期（取代傳統的瀑布型生命周期）
需求和測試驅動
鼓勵用戶積極參與

12、RUP與XP的區別
XP以代碼為中心，編碼和設計活動融為一體，弱化了架構的概念。
RUP過程通常以架構為中心，細化階段的主要目的就是構造出一個可運行的架構原型，作為將來添加需求功能的穩固基礎。
XP不包含業務建模、部署、過程管理等概念。
RUP適合各種規模的項目，XP只適用于小團隊。

13、微軟解決方案框架結構MSF
微軟過程準則：
項目計劃應該兼顧未來的不確定因素;
用有效的風險管理來減少不確定因素的影響;
經常生成并快速的地測試軟件的過渡版本，提高穩定性和可預測性;
采用快速循環，遞進的開發過程;
用創造性的工作來平衡產品特性和產品成本;
項目進度表應該具有較高穩定性和權威性;
使用小型項目組并發的完成開發工作;
在項目早期把軟件配置項基線化，項目后期則凍結產品;
使用原型驗證概念，對項目進行早期論證;
把零缺陷作為追求的目標;
里程碑評審會的目的是改進工作，切忌相互指責.

14、Scrum過程
強調經驗性過程而不是確定性過程
演化型的迭代開發過程

15、軟件過程的選擇與裁剪
每種過程都有其價值，分別具有一些最佳實踐，適合于某類軟件的開發。
軟件過程的選擇：
（1）產品/項目自身的特點
（2）團隊的實際情況和企業文化
（3）客戶的影響
軟件過程進行裁剪
（1）流程歸并與裁剪
（2）角色的篩選與定制
（3）工件的裁剪和定制

16、軟件過程的評估與改進
參考模型：
（1）CMM/CMMI
過程能力成熟度模型（Capability Maturity Model，CMM）
CMMI是一個標準簇（Capability Maturity Model Integration，CMMI）

CMMI for Development（CMMI-DEV）：開發模型
CMMI for Service（CMMI-SVC）：服務模型
CMMI for Acquisition（CMMI-ACQ）：采購模型

CMMI模型不同的改進方法：
組織成熟度方法（階梯式模型）
過程能力方法（連續式模型）

CMMI階梯式模型
初始級->已管理級->已定義級->定量管理級->持續優化級

CMMI的連續性模型
過程管理
項目管理
工程
支持

ISO/IEC 15504
信息技術——軟件過程評價標準，又稱為SPICE

ISO/IEC 20000
用于評估和認證IT運維服務管理過程的能力

總結

以上是生活随笔為你收集整理的软件过程的全部內容，希望文章能夠幫你解決所遇到的問題。

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