軟體過程是整個軟體生命周期中一系列有序的軟體生産活動的流程。為了能高效地開發一個高品質的軟體産品，通常把軟體生命周期中各項開發活動的流程用一個合理的架構——開發模型來規範描述，這就是軟體過程模型，或者稱為軟體生命周期模型。是以，軟體過程模型是一種軟體過程的抽象表示法，“模組化”是軟體過程中最常使用的技術手段之一。
軟體過程模型是從一個特定的角度表現一個過程，一般使用直覺的圖形辨別軟體開發的過程，主要根據軟體的類型、規模，特别是軟體的開發方法、開發環境等多種因素确立過程模型。
過程定義了運用方法的順序、應該傳遞的文檔資料、為保證軟體品質和協調變化所需要采取的管理措施，以及标志軟體開發各個階段任務完成的裡程碑。通常使用生命周期模型簡潔地描述軟體過程。生命周期模型規定了把生命周期劃分成哪些階段及各個階段的執行順序，是以，也稱為過程模型。
幾十年來，軟體工程領域先後出現了多種不同的軟體過程模型，典型的代表是瀑布模型、螺旋模型、演化式模型和面向對象模型。它們各具特色，分别适用于不同特征的軟體項目的開發應用。
1．瀑布模型
在20世紀80年代之前，瀑布模型是最早也是應用最廣泛的軟體過程模型，現在它仍然是軟體工程中應用最廣泛的過程模型。瀑布模型提供了軟體開發的基本架構。其過程是從上一項活動接收該項活動的工作對象作為輸入，利用這一輸入實施該項活動應完成的内容，給出該項活動的工作成果，并作為輸出傳給下一項活動。同時評審該項活動的實施，若确認，則繼續下一項活動；否則傳回前面，甚至更前面的活動。
各個階段産生的文檔是維護軟體産品時必不可少的，沒有文檔的軟體幾乎是不可能維護的。瀑布模型中的文檔限制，使軟體維護變得更加容易。由于絕大部分軟體預算都花費在軟體維護上，是以，使軟體變得比較容易維護就能顯著降低軟體預算。可以說，瀑布模型的成功在很大程度上是由于它基本上是一種文檔驅動的模型。但是，瀑布模型是由文檔驅動，也是其一個主要缺點。軟體産品傳遞給使用者之前，使用者隻能通過文檔來了解産品是什麼樣的。但僅僅通過寫在紙上的規格說明，使用者很難全面正确地認識動态的軟體産品。
瀑布模型将軟體生命周期劃分為軟體計劃、需求分析和定義、軟體設計、軟體實作、軟體測試、軟體運作和維護這6個階段，規定了它們自上而下、互相銜接的固定次序，如同瀑布流水逐級下落。從本質來講，它是一個軟體開發架構，開發過程是通過一系列階段順序展開的，從系統需求分析開始直到産品釋出和維護，每個階段都會産生循環回報，是以，如果有資訊未被覆寫或者發現了問題，那麼最好“傳回”上一個階段并進行适當的修改，開發程序從一個階段“流動”到下一個階段，這也是瀑布開發名稱的由來。采用瀑布模型的軟體過程如圖2-1所示。
按照傳統的瀑布模型開發軟體，有下述的幾個特點。
1）階段的順序性和依賴性：瀑布模型的各個階段之間存在着這樣的關系——後一階段的工作必須等前一階段的工作完成之後才能開始。同時，前一階段的輸出文檔就是後一階段的輸入文檔，是以，隻有前一階段的輸出文檔正确，後一階段的工作才能獲得正确的結果。
2）推遲實作的觀點：對于規模較大的軟體項目來說，往往編碼開始得越早最終完成開發工作所需要的時間越長。主要原因是前面階段的工作沒做或做得不到位，過早地進行下一階段的工作，往往導緻大量返工，有時甚至産生無法彌補的問題，帶來災難性後果。瀑布模型在編碼之前設定了系統分析與系統設計的各個階段。分析與設計階段的基本任務規定，在這兩個階段主要考慮目标系統的邏輯模型，不涉及軟體的程式設計實作。清楚地區分邏輯設計與實體設計，盡可能推遲程式的程式設計實作，是按照瀑布模型開發軟體的一條重要的指導思想。
3）品質保證的觀點：軟體開發最基本的目标是開發效率高，産品品質高。為保證軟體的品質，首先，在瀑布模型的每個階段都必須完成規定的文檔，隻有交出合格的文檔才算是完成該階段的任務。完整、準确的合格文檔不僅是軟體開發時期各類人員之間互相溝通的媒介，也是運作時期對軟體進行維護的重要依據。其次，在每個階段結束前都要對所完成的文檔進行評審，以便盡早發現問題，改正錯誤。事實上，越是早期階段犯下的錯誤，暴露出來的時間就越晚，排除故障改正錯誤所需付出的代價也越高。
4）文檔驅動的觀點：瀑布模型着重強調文檔的作用，并要求每個階段都要仔細驗證。但這種模型的線性過程太理想化，已不再适合現代化軟體開發的模式，其主要問題在于：各個階段的劃分完全固定，階段之間産生大量的文檔，極大地增加了工作量；由于開發模型是線性的，使用者隻有等到整個過程的末期才能見到開發成果，進而增加了開發的風險；客戶要等到開發周期的晚期才能看到程式運作的測試版本，而在這時發現大的錯誤，可能引起客戶的驚慌，後果也可能是災難性的；實際的項目大部分情況難以按照該模型給出的順序進行，而且這種模型的疊代是間接的，這很容易由微小的變化造成大的混亂；采用這種線性模型，會經常在過程的開始和結束時碰到等待其他成員完成其所依賴的任務才能進行下去的情況，有可能花在等待上的時間比開發的時間要長。
2．增量模型
增量模型（incremental model）是在項目的開發過程中以一系列的增量方式開發系統。在增量模型中，軟體被作為一系列的增量構件來設計、實作、內建和測試，每一個構件是由多種互相作用的子產品所形成的提供特定功能的代碼片段構成。
增量方式包括增量開發和增量送出。增量開發是指在項目開發周期内，以一定的時間間隔開發部分工作軟體；增量送出是指在項目開發周期内，以一定的時間間隔增量方式向使用者送出工作軟體及相應文檔。根據增量的方式和形式的不同，分為漸增模型和原型模型。
漸增模型是瀑布模型的變種，有兩類漸增模型：
總體開發增量構造模型：它在瀑布模型的基礎上，對一些階段進行整體開發，對另一些階段進行增量開發。前面的開發階段按瀑布模型進行整體開發，後面的開發階段按增量方式開發。增量構造模型如圖2-2所示。在增量構造模型中，需求分析階段和設計階段都是按瀑布模型的整體方式開發，但是編碼階段和測試階段是按增量方式開發。
增量開發增量送出模型：它在瀑布模型的基礎上，所有階段都進行增量開發，也就是說不僅是增量開發，也是增量送出。在增量送出模型中，項目開發的各個階段都是增量方式。先對某部分功能進行需求分析，然後順序進行設計、編碼、測試，把該功能的軟體傳遞給使用者，然後再對另一部分功能進行開發，送出使用者直至所有功能全部增量開發完畢。
增量構造和增量送出的一些差別：增量構造是在瀑布模型的基礎上，一些階段采用增量開發，另一些階段采用整體開發。增量送出是在瀑布模型的基礎上，所有階段不僅采用增量開發也采用增量送出。
增量構造模型與原型模型和其他演化方法一樣，本質上都是疊代的，但與原型模型不一樣的是，它強調每一個增量都釋出一個可操作的産品。早期的增量是最終産品的“可拆卸”版本，但提供了為使用者服務的功能，并且為使用者提供了評估的平台。
增量模型融合了線性順序模型的基本成分和原型模型的疊代特征。增量模型采用随着日程時間的進展而交錯的線性序列。每一個線性序列産生軟體的一個可釋出的“增量”。當使用增量模型時，第一個增量往往是核心的産品，也就是說第一個增量實作了基本的需求，但很多補充的特征還沒有釋出。客戶對每一個增量的使用和評估，都作為下一個增量釋出的新特征和功能。這個過程在每一個增量釋出後不斷重複，直到産生了最終的完善産品。增量模型強調每一個增量均釋出一個可操作的産品。
增量模型引進了增量包的概念，無須等到所有需求都出來，隻要某個需求的增量包出來即可進行開發。雖然某個增量包可能需要進一步适應客戶的需求并且更改，但隻要這個增量包足夠小，其影響對整個項目來說是可以承受的。
增量模型的人員配置設定靈活，剛開始不用投入大量人力資源；如果核心産品很受歡迎，則可增加人力實作下一個增量；當配備的人員不能在設定的期限内完成産品時，它提供了一種先推出核心産品的途徑。這樣即可先釋出部分功能給客戶，以便穩定客戶。此外，增量能夠有計劃地管理技術風險。
增量模型在各個階段并不傳遞一個可運作的完整産品，而是傳遞滿足客戶需求的可運作産品的一個子集。整個産品被分解成若幹個構件，開發人員逐個傳遞産品，這樣軟體開發可以很好地适應變化，客戶可以不斷地看到所開發的軟體，進而降低開發風險。但是，增量模型也存在以下缺陷：
1）各個構件是逐漸并入已有的軟體體系結構中的，是以加入構件必須不破壞已構造好的系統部分，這需要軟體具備開放式的體系結構。
2）在實際的軟體開發過程中，需求的變化是不可避免的。增量模型的靈活性可以使其适應這種變化的能力大大優于瀑布模型，但也很容易退化為邊做邊改模型，進而使軟體過程的控制失去整體性。
3）如果增量包之間存在相交的情況且未很好的處理，則必須做全盤系統分析，這種模型将功能細化後分别開發的方法較适用于需求經常改變的軟體開發過程。
3．螺旋模型
螺旋模型（spiral model）是在1988年，由barry boehm正式提出的模型，它将瀑布模型和快速原型模型結合起來，它不僅展現了兩個模型的優點，而且還強調了其他模型均忽略了風險分析，特别适合于大型複雜的系統。這種模型的每一個周期都包括需求定義、風險分析、工程實作和評審4個階段，由這4個階段進行疊代。軟體開發過程每疊代一次，軟體開發就前進一個層次。采用螺旋模型的軟體過程如圖2-3所示。
在“瀑布模型”的每一個開發階段前引入非常嚴格的風險識别、風險分析和風險控制，它把軟體項目分解成一個個小項目。每個小項目都辨別一個或多個主要風險，直到所有的主要風險因素都被确定。該模型沿着螺旋線進行若幹次疊代，圖中的四個象限分别代表了以下活動：
1）制定計劃：确定軟體目标，標明實施方案，确定項目開發的限制條件。
2）風險分析：分析評估所選方案，考慮如何識别和消除風險。
3）實施工程：實施軟體開發和驗證。
4）客戶評估：評價開發工作，提出修正建議，制定下一步計劃。
螺旋模型有許多優點：對可選方案和限制條件的強調有利于已有軟體的重用，也有助于把軟體品質作為軟體開發的一個重要目标；減少了過多測試或測試不足所帶來的風險；更重要的是，在螺旋模型中維護隻是模型的另一個周期，在維護和開發之間并沒有本質差別。與瀑布模型相比，螺旋模型支援使用者需求的動态變化，為使用者參與軟體開發的所有關鍵決策提供了友善，有助于提高目标軟體的适應能力。并且為項目管理人員及時調整管理決策提供了便利，進而降低了軟體開發風險。
螺旋模型由風險驅動，強調可選方案和限制條件進而支援軟體的重用，幫助我們将軟體品質作為特殊目标融入産品開發之中。但螺旋模型也有一定的限制條件：螺旋模型強調風險分析，使得開發人員和使用者對每個演化層出現的風險有所了解，繼而做出應有的反應，是以特别适用于複雜并具有高風險的系統。對于這些系統，風險是軟體開發不可忽視且潛在的不利因素，它可能在不同程度上損害軟體開發過程，影響軟體産品的品質。減小軟體風險的目标是在造成危害之前，及時對風險進行識别及分析，決定采取何種對策，進而消除或減少風險的損害。
如果執行風險分析将大大影響項目的利潤，則風險分析是不可行的，那麼進行風險分析就顯得毫無意義，是以，螺旋模型隻适合于大規模軟體項目。事實上，項目越大，風險也越大，是以，進行風險分析的必要性也越大。此外，隻有内部開發的項目，才能在風險過大時中止項目。螺旋模型的主要優勢在于，它是風險驅動的，但是，這也可能是它的一個劣勢。軟體開發人員應該擅長尋找可能的風險，準确地分析風險，否則将會帶來更大的風險。
從方法學的角度可以認為，面向對象的方法是面向對象的世界觀在開發方法中的直接運用。它強調系統的結構應該直接與現實世界的結構相對應，應該圍繞現實世界中的對象來構造系統，而不是圍繞功能來構造系統。
正确地運用面向對象方法學開發軟體，則最終的軟體産品由許多較小的、基本上獨立的對象組成，每個對象相當于一個小型的程式，而且大多數對象都與現實世界中的實體相對應，這樣就降低了軟體産品的複雜性，提高了軟體的可了解性，簡化了軟體的開發和維護工作。對象是相對獨立的實體，可以在以後的軟體産品中複用。基于此，面向對象範型的另一個重要優點是促進了軟體複用。面向對象方法特有的繼承性和多态性，進一步提高了面向對象軟體的可重用性。
1．統一過程模型
統一過程（unified process，up）是風險驅動的、基于用例技術的、以架構為中心的、疊代的、可配置的軟體開發流程。up是一個面向對象且基于網絡的程式開發方法論。根據rational rose和統一模組化語言的開發者的說法，它可以為所有方面和層次的程式開發提供指導方針、模闆以及事例支援。
統一過程是一個軟體開發過程，是一個通用的過程架構，可以用于各類軟體系統和應用領域。統一過程是以用例驅動的，以架構為中心，疊代和增量的過程。統一過程是在重複一系列組成系統生命周期的循環。每一次循環包括4個階段：初始、細化、構造和移交。每個階段又進一步細分為多次疊代的過程，如圖2-4所示。
每次循環疊代會産生一個新的版本，每個版本都是一個準備傳遞的産品。
1）初始階段。在初始階段形成将好的想法發展為最終産品的構想，提出了該産品的業務執行個體。該階段要完成：系統向它的每個重要使用者提供的基本功能是什麼？該系統的邏輯架構大概是什麼樣子？開發該産品的計劃如何？開銷多大？在該階段主要建立關鍵用例的簡化用例模型，用于刻畫系統主要功能。架構是實驗性的，通常是包括主要子系統的大緻的輪廓。要确定最主要的風險及其優先次序，要對細化階段進行詳細規劃，并對項目進行粗略估算。
2）細化階段。在細化階段，詳細說明該系統的絕大多數用例，并設計出系統的架構。架構可以表示為系統中所有模型的不同視圖，合起來表示整個系統，即架構包括用例模型、分析模型、設計模型、實作模型和實施模型的視圖。在細化階段末期，要規劃完成項目的活動，估算完成項目所需的資源。關鍵問題是用例、架構和計劃是否足夠穩定、可靠，風險是否得到控制，以便按照合同的規定完成整個開發任務。該階段的結果是架構基線。
3）構造階段。構造階段将構造出最終産品——軟體。在該階段架構基線逐漸發展成為完善的系統，将消除所需要的大部分資源，架構可以進行微調，但系統架構是穩定可靠的。要回答的問題是早期傳遞給客戶的産品是否完全滿足客戶的需求。
4）移交階段。移交階段包括産品進入分析後期的整個階段，使用者使用分析法發現産品的缺陷和不足，開發人員改正問題及完善系統形成更通用的版本。該階段包括制作、使用者教育訓練、提供線上支援以及改正傳遞之後發現的缺陷活動。
統一過程在定義4個階段及其疊代過程時，又給出了5個核心工作流：需求、分析、設計、實作和測試。每個工作流在各個階段所處的地位和工作是不同的。圖2-5給出了統一過程的核心工作流。
1）需求工作流。需求工作流的目的是緻力于開發正确的系統。需求工作流就是要足夠詳細地描述系統需求，使客戶和開發人員在系統應該做什麼和不應該做什麼方面達成共識。
2）分析工作流。分析工作流的目的是更精确地了解需求，也是為了得到一個易于維護且有助于确定系統結構的需求描述。與需求工作流相比，分析工作流可以采用開發人員熟悉的語言來描述群組織需求。分析工作流的任務是探究系統内部，解決用例間的幹擾以及類似的問題。分析得到的需求結構可用作構造整個系統的基本輸入。分析工作流使用分析模型表達系統的本質。
3）設計工作流。設計工作流的目的是深入了解與非功能性需求和限制相聯系的程式設計語言、構件使用、作業系統、分布與并發技術、資料庫技術、使用者界面技術和事務管理技術等相關問題。設計工作流要把實作工作劃分成更易于管理的各個部分，捕獲早期子系統之間的主要接口，建立對系統實行的無縫抽象。
4）實作工作流。實作工作流探讨如何用源代碼、腳本、二進制代碼、可執行體等構件來實作系統。實作工作流的目的是規劃每次疊代中所要求的系統內建，通過把可執行構件映射到實施模型中的節點的方式來分布系統，實作設計過程中發現的設計類和子系統，對構件進行單元測試。
5）測試工作流。測試工作流通過測試每一個增量來驗證實作的結構。測試工作流的目的是為了規劃每一次疊代需要的測試工作，包括內建測試和系統測試。測試工作流的任務是設計和實作測試，執行各種測試并系統地處理每個測試的結果。
統一過程描述了如何為軟體開發團隊有效地部署經過商業化驗證的軟體開發方法。它的目标是在可預見的日程和預算前提下，確定開發出滿足最終使用者需求的高品質産品。為使整個團隊有效利用最佳實踐，統一過程為每個團隊成員提供了必要準則、模闆和工具指導。
1）疊代軟體開發。針對複雜的軟體系統，rup使用連續的開發方法，并支援專注于處理生命周期中每個階段中最高風險的疊代開發方法，極大地減少了項目的風險性。疊代方法通過可驗證的方法來幫助減少風險——增量送出的可執行版本使最終使用者不斷地介入和回報。
2）需求管理。統一過程描述了如何提取、組織和文檔化需要的功能與限制。它們給開發和釋出系統提供了連續的和可跟蹤的線索。捕獲功能性需求使用了用例和場景，并確定由它們來驅動設計、實作和軟體的測試，使開發出的軟體更加滿足最終使用者的需要。
3）基于構件的體系結構。統一過程支援基于構件的軟體開發。構件是實作清晰功能的子產品、子系統。在開發之前，關注早期的開發和健壯可執行體系結構的基線。它描述了如何設計靈活的、可容納修改的、直覺便于了解的，并且促進有效軟體重用的彈性結構。
4）可視化軟體模組化。開發過程注重可視化模組化，捕獲體系結構和構件的構架與行為。這樣，我們就可以隐藏細節和使用“圖形構件塊”來書寫代碼。可視化抽象能幫助我們溝通軟體的不同方面，觀察各元素如何配合在一起，確定構件子產品與代碼一緻，保持設計和實作的一緻性，促進明确的溝通。rational軟體公司建立的工業級标準統一模組化語言（unified modeling language，uml)是成功可視化軟體模組化的基礎。
5）驗證軟體品質。品質應該基于可靠性、功能性、應用和系統性能，根據需求來進行驗證。up幫助計劃、設計、實作、執行和評估這些測試類型。
6）控制軟體變更。開發過程描述了如何控制、跟蹤和監控修改以確定成功的疊代開發。它同時指導如何通過隔離修改和控制整個軟體産物的修改來為每個開發者建立安全的工作區。
統一過程主要的優點：提高了團隊生産力，在疊代的開發過程、需求管理、基于構件的體系結構、可視化軟體模組化、驗證軟體品質及控制軟體變更等方面，針對所有關鍵的開發活動為每個開發成員提供了必要的準則、模闆和工具指導，并確定全體成員共享相同的知識基礎。統一過程也存在一些缺點：統一過程隻是一個開發過程，并沒有涵蓋軟體過程的全部内容，如它在軟體運作和支援等方面的内容略有不足；此外，它沒有支援多項目的開發結構，這在一定程度上降低了在開發組織内大範圍實作重用的可能性。統一過程是一個非常好的開端，但并不完美，在實際的應用中可以根據需要對其進行改進并可以用其他軟體過程的相關模型對統一過程進行補充和完善。
2．構件內建模型
構件內建模型利用子產品化方法将整個系統子產品化，并在一定構件模型的支援下複用構件庫中的軟體構件，通過組合手段提高應用軟體系統過程的效率和品質。構件內建模型融合了螺旋模型的許多特征，本質上是演化型的，開發過程是疊代的。構件內建模型由軟體的需求分析和定義、體系結構設計、構件庫建立、應用軟體建構，以及測試和釋出5個階段組成，如圖2-6所示。
基于構件的開發活動從辨別候選構件開始，通過搜查已有構件庫，确認所需要的構件是否已經存在。如果已經存在，則從構件庫中提取出來複用；否則采用面向對象的方法開發它。之後在提取出來的構件通過文法和語義檢查後，将這些構件通過代碼組裝到一起實作系統，這個過程是疊代的。基于構件的開發方法使得軟體開發不再一切從頭開發，開發的過程就是構件組裝的過程，維護的過程就是構件更新、替換和擴充的過程。其優點是構件內建模型導緻了軟體的複用，提高了軟體開發的效率。
由于采用自定義的組裝結構标準，缺乏通用的組裝結構标準，這樣就引入了比較大的風險。可重用性和軟體高效性不容易協調，這就需要比較有開發經驗的開發人員，而一般的開發人員很難開發出令客戶滿意的軟體。由于過分依賴于構件，是以構件庫的品質影響着産品品質。
構件內建模型融合了螺旋模型的很多特征，支援軟體開發的疊代方法。這種面向複用的過程模型，最明顯的優勢是減少了需要開發的軟體數量，加快了軟體傳遞，進而降低了開發成本，同時也降低了開發風險。當然，它的成功主要是依賴于可複用軟體構件，以及能內建這些軟體構件的架構。