正如任何事物一樣，軟件也有其孕育、誕生、成長、成熟和衰亡的生存過程，一般稱其為“軟件生命周期”。軟件生命周期一般分為6個階段，即制定計劃、需求分析、設計、編碼、測試、運行和維護。軟件開發的各個階段之間的關系不可能是順序且線性的，而應該是帶有反饋的迭代過程。在軟件工程中，這個復雜的過程用軟件開發模型來描述和表示。

軟件開發模型是跨越整個軟件生存周期的系統開發、運行和維護所實施的全部工作和任務的結構框架，它給出了軟件開發活動各階段之間的關系。目前，常見的軟件開發模型大致可分為如下3種類型：

① 以軟件需求完全確定為前提的瀑布模型（Waterfall Model）。

② 在軟件開發初始階段只能提供基本需求時采用的漸進式開發模型，如螺旋模型（Spiral Model）。

③ 以形式化開發方法為基礎的變換模型（Transformational Model）。

下面將簡單地比較并分析瀑布模型、螺旋模型和變換模型等軟件開發模型。

瀑布模型

瀑布模型即生存周期模型，其核心思想是按工序將問題化簡，將功能的實現與設計分開，便于分工協作，即采用結構化的分析與設計方法將邏輯實現與物理實現分開。瀑布模型將軟件生命周期劃分為軟件計劃、需求分析和定義、軟件設計、軟件實現、軟件測試、軟件運行和維護這6個階段，規定了它們自上而下、相互銜接的固定次序，如同瀑布流水逐級下落。瀑布模型是最早出現的軟件開發模型，在軟件工程中占有重要的地位，它提供了軟件開發的基本框架。瀑布模型的本質是一次通過，即每個活動只執行一次，最后得到軟件產品，也稱為“線性順序模型”或者“傳統生命周期”。其過程是從上一項活動接收該項活動的工作對象作為輸入，利用這一輸入實施該項活動應完成的內容給出該項活動的工作成果，并作為輸出傳給下一項活動。同時評審該項活動的實施，若確認，則繼續下一項活動；否則返回前面，甚至更前面的活動。

瀑布模型有利于大型軟件開發過程中人員的組織及管理，有利于軟件開發方法和工具的研究與使用，從而提高了大型軟件項目開發的質量和效率。然而軟件開發的實踐表明，上述各項活動之間并非完全是自上而下且呈線性圖式的，因此瀑布模型存在嚴重的缺陷：

① 由于開發模型呈線性，所以當開發成果尚未經過測試時，用戶無法看到軟件的效果。這樣軟件與用戶見面的時間間隔較長，也增加了一定的風險。

② 在軟件開發前期末發現的錯誤傳到后面的開發活動中時，可能會擴散，進而可能會造成整個軟件項目開發失敗。

③ 在軟件需求分析階段，完全確定用戶的所有需求是比較困難的，甚至可以說是不太可能的。

螺旋模型

螺旋模型將瀑布和演化模型（Evolution Model）結合起來，它不僅體現了兩個模型的優點，而且還強調了其他模型均忽略了的風險分析。這種模型的每一個周期都包括需求定義、風險分析、工程實現和評審4個階段，由這4個階段進行迭代。軟件開發過程每迭代一次，軟件開發又前進一個層次。

螺旋模型基本做法是在“瀑布模型”的每一個開發階段前引入一個非常嚴格的風險識別、風險分析和風險控制，它把軟件項目分解成一個個小項目。每個小項目都標識一個或多個主要風險，直到所有的主要風險因素都被確定。

螺旋模型強調風險分析，使得開發人員和用戶對每個演化層出現的風險有所了解，繼而做出應有的反應，因此特別適用于龐大、復雜并具有高風險的系統。對于這些系統，風險是軟件開發不可忽視且潛在的不利因素，它可能在不同程度上損害軟件開發過程，影響軟件產品的質量。減小軟件風險的目標是在造成危害之前，及時對風險進行識別及分析，決定采取何種對策，進而消除或減少風險的損害。

與瀑布模型相比，螺旋模型支持用戶需求的動態變化，為用戶參與軟件開發的所有關鍵決策提供了方便，有助于提高目標軟件的適應能力。并且為項目管理人員及時調整管理決策提供了便利，從而降低了軟件開發風險。

但是，我們不能說螺旋模型絕對比其他模型優越，事實上，這種模型也有其自身的如下缺點。

① 采用螺旋模型需要具有相當豐富的風險評估經驗和專門知識，在風險較大的項目開發中，如果未能夠及時標識風險，勢必造成重大損失。

② 過多的迭代次數會增加開發成本，延遲提交時間。

變換模型

變換模型是基于形式化規格說明語言及程序變換的軟件開發模型，它采用形式化的軟件開發方法對形式化的軟件規格說明進行一系列自動或半自動的程序變換，最后映射為計算機系統能夠接受的程序系統。

為了確認形式化規格說明與軟件需求的一致性，往往以形式化規格說明為基礎開發一個軟件原型，用戶可以從人機界面、系統主要功能和性能等幾個方面對原型進行評審。必要時，可以修改軟件需求、形式化規格說明和原型，直至原型被確認為止。這時軟件開發人員即可對形式化的規格說明進行一系列的程序變換，直至生成計算機系統可以接受的目標代碼。

“程序變換”是軟件開發的另一種方法，其基本思想是把程序設計的過程分為生成階段和改進階段。首先通過對問題的分析制定形式規范并生成一個程序，通常是一種函數型的“遞歸方程”。然后通過一系列保持正確性的源程序到源程序的變換，把函數型風格轉換成過程型風格并進行數據結構和算法的求精，最終得到一個有效的面向過程的程序。這種變換過程是一種嚴格的形式推導過程，所以只需對變換前的程序的規范加以驗證，變換后的程序的正確性將由變換法則的正確性來保證。

變換模型的優點是解決了代碼結構經多次修改而變壞的問題，減少了許多中間步驟（如設計、編碼和測試等）。但是變換模型仍有較大局限，以形式化開發方法為基礎的變換模型需要嚴格的數學理論和一整套開發環境的支持，目前形式化開發方法在理論、實踐和人員培訓方面距工程應用尚有一段距離。

基于構件的開發模型

基于構件的開發模型利用模塊化方法將整個系統模塊化，并在一定構件模型的支持下復用構件庫中的一個或多個軟件構件，通過組合手段高效率、高質量地構造應用軟件系統的過程。基于構件的開發模型融合了螺旋模型的許多特征，本質上是演化形的，開發過程是迭代的。基于構件的開發模型由軟件的需求分析和定義、體系結構設計、構件庫建立、應用軟件構建，以及測試和發布5個階段組成

構件作為重要的軟件技術和工具得到極大的發展，這些新技術和工具有Microsoft的DCOM、Sun的EJB，以及OMG的CORBA等。基于構件的開發活動從標識候選構件開始，通過搜查已有構件庫，確認所需要的構件是否已經存在。如果已經存在，則從構件庫中提取出來復用；否則采用面向對象方法開發它。之后利用提取出來的構件通過語法和語義檢查后將這些構件通過膠合代碼組裝到一起實現系統，這個過程是迭代的。

基于構件的開發方法使得軟件開發不再一切從頭開發，開發的過程就是構件組裝的過程，維護的過程就是構件升級、替換和擴充的過程。其優點是構件組裝模型導致了軟件的復用，提高了軟件開發的效率。構件可由一方定義其規格說明，被另一方實現。然后供給第三方使用，構件組裝模型允許多個項目同時開發，降低了費用，提高了可維護性，可實現分步提交軟件產品。

由于采用自定義的組裝結構標準，缺乏通用的組裝結構標準，因而引入了較大的風險。可重用性和軟件高效性不易協調，需要精干的有經驗的分析和開發人員，一般開發人員插不上手。客戶的滿意度低，并且由于過分依賴于構件，所以構件庫的質量影響著產品質量。

其他：

噴泉模型

噴泉模型是一種以用戶需求為動力，以對象為驅動的模型，主要用于描述面向對象的軟件開發過程。該模型認為軟件開發過程自下而上周期的各階段是相互重疊和多次反復的，就像水噴上去又可以落下來，類似一個噴泉。各個開發階段沒有特定的次序要求，并且可以交互進行，可以在某個開發階段中隨時補充其他任何開發階段中的遺漏。

噴泉模型主要用于面向對象的軟件項目，軟件的某個部分通常被重復多次，相關對象在每次迭代中隨之加入漸進的軟件成分。各活動之間無明顯邊界，例如設計和實現之間沒有明顯的邊界，這也稱為“噴泉模型的無間隙性”。由于對象概念的引入，表達分析、設計及實現等活動只用對象類和關系，從而可以較容易地實現活動的迭代和無間隙。

噴泉模型不像瀑布模型那樣，需要分析活動結束后才開始設計活動，設計活動結束后才開始編碼活動。該模型的各個階段沒有明顯的界限，開發人員可以同步進行開發。其優點是可以提高軟件項目開發效率，節省開發時間，適應于面向對象的軟件開發過程。由于噴泉模型在各個開發階段是重疊的，因此在開發過程中需要大量的開發人員，因此不利于項目的管理。此外這種模型要求嚴格管理文檔，使得審核的難度加大，尤其是面對可能隨時加入各種信息、需求與資料的情況。

智能模型

智能模型也稱為“基于知識的軟件開發模型”，它把瀑布模型和專家系統結合在一起，利用專家系統來幫助軟件開發人員的工作。該模型應用基于規則的系統，采用歸納和推理機制，使維護在系統規格說明一級進行。這種模型在實施過程中以軟件工程知識為基礎的生成規則構成的知識系統與包含應用領域知識規則的專家系統相結合，構成這一應用領域軟件的開發系統。智能模型所要解決的問題是特定領域的復雜問題，涉及大量的專業知識，而開發人員一般不是該領域的專家，他們對特定領域的熟悉需要一個過程，所以軟件需求在初始階段很難定義得很完整。因此，采用原型實現模型需要通過多次迭代來精化軟件需求。

智能模型以知識作為處理對象，這些知識既有理論知識，也有特定領域的經驗。在開發過程中需要將這些知識從書本中和特定領域的知識庫中抽取出來（即知識獲取），選擇適當的方法進行編碼（即知識表示）建立知識庫。將模型、軟件工程知識與特定領域的知識分別存入數據庫，在這個過程中需要系統開發人員與領域專家的密切合作。

智能模型開發的軟件系統強調數據的含義，并試圖使用現實世界的語言表達數據的含義。該模型可以勘探現有的數據，從中發現新的事實方法指導用戶以專家的水平解決復雜的問題。它以瀑布模型為基本框架，在不同開發階段引入了原型實現方法和面向對象技術以克服瀑布模型的缺點，適應于特定領域軟件和專家決策系統的開發。

增量模型

增量模型融合了瀑布模型的基本成分（重復應用）和原型實現的迭代特征，該模型采用隨著日程時間的進展而交錯的線性序列，每一個線性序列產生軟件的一個可發布的“增量”。當使用增量模型時，第1個增量往往是核心的產品，即第1個增量實現了基本的需求，但很多補充的特征還沒有發布。客戶對每一個增量的使用和評估都作為下一個增量發布的新特征和功能，這個過程在每一個增量發布后不斷重復，直到產生了最終的完善產品。增量模型強調每一個增量均發布一個可操作的產品。采用增量模型的軟件過程如圖1-8所示。

增量模型與原型實現模型和其他演化方法一樣，本質上是迭代的，但與原型實現不一樣的是其強調每一個增量均發布一個可操作產品。早期的增量是最終產品的“可拆卸”版本，但提供了為用戶服務的功能，并且為用戶提供了評估的平臺。增量模型的特點是引進了增量包的概念，無須等到所有需求都出來，只要某個需求的增量包出來即可進行開發。雖然某個增量包可能還需要進一步適應客戶的需求并且更改，但只要這個增量包足夠小，其影響對整個項目來說是可以承受的。

采用增量模型的優點是人員分配靈活，剛開始不用投入大量人力資源。如果核心產品很受歡迎，則可增加人力實現下一個增量。當配備的人員不能在設定的期限內完成產品時，它提供了一種先推出核心產品的途徑。這樣即可先發布部分功能給客戶，對客戶起到鎮靜劑的作用。此外，增量能夠有計劃地管理技術風險。增量模型的缺點是如果增量包之間存在相交的情況且未很好處理，則必須做全盤系統分析，這種模型將功能細化后分別開發的方法較適應于需求經常改變的軟件開發過程。

原型實現模型

原型實現模型從需求收集開始，開發者和客戶在一起定義軟件的總體目標，標識出已知的需求，并規劃出需要進一步定義的區域。然后是“快速設計”，即集中于軟件中那些對用戶／客戶可見的部分的表示。這將導致原型的創建，并由用戶／客戶評估并進一步精化待開發軟件的需求。逐步調整原型使其滿足客戶的要求，而同時也使開發者對將要做的事情有更好的理解。這個過程是迭代的，其流程從聽取客戶意見開始，隨后是建造／修改原型、客戶測試運行原型。然后往復循環，直到客戶對原型滿意為止。

原型實現模型的最大特點是能夠快速實現一個可實際運行的系統初步模型，供開發人員和用戶進行交流和評審，以便較準確地獲得用戶的需求。該模型采用逐步求精方法使原型逐步完善，即每次經用戶評審后修改、運行，不斷重復得到雙方認可。這個過程是迭代過程，它可以避免在瀑布模型冗長的開發過程中看不見產品雛形的現象。其優點一是開發工具先進，開發效率高，使總的開發費用降低，時間縮短；二是開發人員與用戶交流直觀，可以澄清模糊需求，調動用戶的積極參與，能及早暴露系統實施后潛在的一些問題；三是原型系統可作為培訓環境，有利于用戶培訓和開發同步，開發過程也是學習過程。

原型實現模型的缺點是產品原型在一定程度上限制了開發人員的創新，沒有考慮軟件的整體質量和長期的可維護性。由于達不到質量要求產品可能被拋棄，而采用新的模型重新設計，因此原型實現模型不適合嵌入式、實時控制及科學數值計算等大型軟件系統的開發。

增量模型和原型模型都是從概要需求出發開發的，但二者有明顯不同。增量模型是從一些不完整的系統需求出發開始開發，在開發過程中逐漸發現新的需求。然后進一步充實完善該系統，使之成為實際可用的系統；原型開發的目的是為了發現并建立一個完整并經過證實的需求規格說明，然后以此作為正式系統的開發基礎。因此原型開發階段的輸出是需求規格說明，這是為了降低整個軟件生成期的費用而拉大需求分析階段的一種方法，大部分原型是“用完就扔”的類型。

XP方法

敏捷方法是近幾年興起的一種輕量級的開發方法，它強調適應性而非預測性、強調以人為中心，而不以流程為中心，以及對變化的適應和對人性的關注，其特點是輕載、基于時間、Just Enough、并行并基于構件的軟件過程。在所有的敏捷方法中，XP（eXtreme Programming）方法是最引人注目的一種輕型開發方法。它規定了一組核心價值和方法，消除了大多數重量型過程的不必要產物，建立了一個漸進型開發過程。該方法將開發階段的4個活動（分析、設計、編碼和測試）混合在一起，在全過程中采用迭代增量開發、反饋修正和反復測試。它把軟件生命周期劃分為用戶故事、體系結構、發布計劃、交互、接受測試和小型發布6個階段。XP模型通過對傳統軟件開發的標準方法進行重新審視，提出了由一組規則組成的一些簡便易行的過程。由于這些規則是通過在實踐中觀察使軟件高效或緩慢的因素而得出的，因此它既考慮了保持開發人員的活力和創造性，又考慮了開發過程的有組織、有重點和持續性。XP模型是面向客戶的開發模型，重點強調用戶的滿意程度。開發過程中對需求改變的適應能力較高，即使在開發的后期，也可較高程度地適應用戶的改變。

XP開發模型與傳統模型相比具有很大的不同，其核心思想是交流（Communication）、簡單（Simplicity）、反饋（Feedback）和進取（Aggressiveness）。XP開發小組不僅包括開發人員，還包括管理人員和客戶。該模型強調小組內成員之間要經常進行交流，在盡量保證質量可以運行的前提下力求過程和代碼的簡單化；來自客戶、開發人員和最終用戶的具體反饋意見可以提供更多的機會來調整設計，保證把握正確的開發方向；進取則包含于上述3個原則中。

XP開發方法中有許多新思路，如采用“用戶故事”代替傳統模型中的需求分析，“用戶故事”由用戶用自己領域中的詞匯并且不考慮任何技術細節準確地表達自己的需求。XP模型的優點如下。

① 采用簡單計劃策略，不需要長期計劃和復雜模型，開發周期短。

② 在全過程采用迭代增量開發、反饋修正和反復測試的方法，軟件質量有保證。

③ 能夠適應用戶經常變化的需求，提供用戶滿意的高質量軟件。

小結

軟件工程是集成計算機軟件開發的過程、方法和工具的學科，已經產生的一系列的軟件工程過程模型各自有其優點和缺點，但是它們均有一系列共同的一般階段。

軟件過程模型發展經歷了以下階段。

① 以軟件需求完全確定為前提的第1代軟件過程模型，如瀑布模型等。這類開發模型的特點是軟件需求在開發階段已經被完全確定，將生命周期的各項活動依順序固定，強調開發的階段性；其缺點是開發后期要改正早期存在的問題需要付出很高的代價，用戶需要等待較長時間才能夠看到軟件產品，增加了風險系數。并且如果在開發過程存在阻塞問題，則影響開發效率。

② 在開始階段只能提供基本需求的漸進式開發模型，如螺旋模型和原型實現模型等。這類開發模型的特點是軟件開發開始階段只有基本的需求，軟件開發過程的各個活動是迭代的。通過迭代過程實現軟件的逐步演化，最終得到軟件產品。在此引入了風險管理，采取早期預防措施，增加項目成功幾率，提高軟件質量；其缺點是由于需求的不完全性，從而為軟件的總體設計帶來了困難和削弱了產品設計的完整性，并要求對風險技能管理水平的高要求。

③ 以體系結構為基礎的基于構件組裝的開發模型，如基于構件的開發模型和基于體系結構的開發模型等。這類模型的特點是利用需求分析結果設計出軟件的總體結構，通過基于構件的組裝方法來構造軟件系統。軟件體系結構的出現使得軟件的結構框架更清晰，有利于系統的設計、開發和維護。

綜上所述，軟件開發模型隨著軟件設計思想的改變而發展，經歷了由最初以結構化程序設計思想為指導的瀑布模型等，到以面向對象思想為指導的噴泉模型等，到以構件開發思想為指導的基于體系結構的開發模型等，到現在的4GT技術。每次新的軟件設計思想的突破都會出現新的軟件開發過程模型，以達到提高軟件的生產效率和質量為目標，提出新的解決“軟件危機”問題的方案。