如同任何事物都有一個發生、發展、成熟，直至衰亡的全過程一樣，軟件系統或軟件產品 也有一個定義、開發、運行維護，直至被淘汰這樣的全過程，我們把軟件將要經歷的這個全過 程稱為軟件的生命周期。 為了使軟件生命周期中的各項任務能夠有序地按照規程進行，需要一定的工作模型對各項 任務給以規程約束，這樣的工作模型被稱為軟件過程模型，或軟件生命周期模型。它是一個有 關項目任務的結構框架，規定了軟件生命周期內各項任務的執行步驟與目標。 本章將介紹瀑布模型、原型模型、螺旋模型、噴泉模型和組件模型等過程模型。需要注意 的是，這些模型並不是有關軟件開發進程的固定格式，而只是一種參考標准。實際上，不同的 軟件項目需要不同的過程模型提供支持，並且還需要根據項目的具體情況，軟件開發機構工作方式、管理模式等，對一些標准模型進行適當的調整與補充，以適應項目應用的需要。
一、軟件生命周期
根據我國國家標准《計算機軟件開發規范》（GB 8566—8），軟件生命周期包含：軟件定義、 軟件開發、軟件運行維護三個時期，並可以細分為可行性研究、項目計划、需求分析、概要設 計、詳細設計、編碼實現與單元測試、系統集成測試、系統確認驗證、系統運行與維護等幾個 階段。應該說，這是軟件生命周期的基本構架，在實際軟件項目中，根據所開發軟件的規模、 種類，軟件開發機構的習慣做法，以及軟件開發中所采用的技術方法等，可以對各階段進行必 要的合並、分解或補充。
1.軟件定義期
軟件定義是軟件項目的早期階段，主要由軟件系統分析人員和用戶合作，針對有待開發的 軟件系統進行分析、規划和規格描述，確定軟件是什么，為今后的軟件開發做准備。這個時期 往往需要分階段地進行以下幾項工作。
（1）軟件任務立項
軟件項目往往開始於任務立項，並需要以“軟件任務立項報告”的形式針對項目的名稱、 性質、目標、意義和規模等作出回答，以此獲得對准備着手開發的軟件系統的最高層描述。
（2）項目可行性分析
在軟件任務立項報告被批准以后，接着需要進行項目可行性分析。 可行性分析是針對准備進行的軟件項目進行的可行性風險評估。因此，需要對准備開發的 軟件系統提出高層模型，並根據高層模型的特征，從技術可行性、經濟可行性和操作可行性這 三個方面，以“可行性研究報告”的形式，對項目作出是否值得往下進行的回答，由此決定項 目是否繼續進行下去。
(3) 制定項目計划
在確定項目可以進行以后，接着需要針對項目的開展，從人員、組織、進度、資金、設備 等多個方面進行合理的規划，並以“項目開發計划書”的形式提交書面報告。
(4) 軟件需求分析
軟件需求分析是軟件規格描述的具體化與細節化，是軟件定義時期需要達到的目標。 需求分析要求以用戶需求為基本依據，從功能、性能、數據、操作等多個方面，對軟件系 統給出完整、准確、具體的描述，用於確定軟件規格。其結果將以“軟件需求規格說明書”的 形式提交。 在軟件項目進行過程中，需求分析是從軟件定義到軟件開發的最關鍵步驟，其結論不僅是今后軟件開發的基本依據，同時也是今后用戶對軟件產品進行驗收的基本依據。
2.軟件開發期
在對軟件規格完成定義以后，接着可以按照“軟件需求規格說明書”的要求對軟件實施開 發，並由此制作出軟件產品。這個時期需要分階段地完成以下幾項工作。
（1）軟件概要設計
概要設計是針對軟件系統的結構設計，用於從總體上對軟件的構造、接口、全局數據結構 和數據環境等給出設計說明，並以“概要設計說明書”的形式提交書面報告，其結果將成為詳細設計與系統集成的基本依據。 模塊是概要設計時構造軟件的基本元素，因此，概要設計中軟件也就主要體現在模塊的構 成與模塊接口這兩個方面上。結構化設計中的函數、過程，面向對象設計中的類、對象，它們都 是模塊。概要設計時並不需要說明模塊的內部細節，但是需要進行全部的有關它們構造的定義， 包括功能特征、數據特征和接口等。 在進行概要設計時，模塊的獨立性是一個有關質量的重要技術性指標，可以使用模塊的內 聚、耦合這兩個定性參數對模塊獨立性進行度量。
（2）軟件詳細設計
設計工作的第二步是詳細設計，它以概要設計為依據，用於確定軟件結構中每個模塊的內 部細節，為編寫程序提供最直接的依據。 詳細設計需要從實現每個模塊功能的程序算法和模塊內部的局部數據結構等細節內容上 給出設計說明，並以“詳細設計說明書”的形式提交書面報告。
（3）編碼和單元測試
編碼是對軟件的實現，一般由程序員完成，並以獲得源程序基本模塊為目標。 編碼必須按照“詳細設計說明書”的要求逐個模塊地實現。在基於軟件工程的軟件開發過 程中，編碼往往只是一項語言轉譯工作，即把詳細設計中的算法描述語言轉譯成某種適當的高 級程序設計語言或匯編語言。 為了方便程序調試，針對基本模塊的單元測試也往往和編碼結合在一起進行。單元測試也以 “詳細設計說明書”為依據，用於檢驗每個基本模塊在功能、算法與數據結構上是否符合設計要求。
（4）系統集成測試
所謂系統集成也就是根據概要設計中的軟件結構，把經過測試的模塊，按照某種選定的集成策略，例如漸增集成策略，將系統組裝起來。 在組裝過程中，需要對整個系統進行集成測試，以確保系統在技術上符合設計要求，在應用上滿足需求規格要求。
（5）系統確認驗證
在完成對系統的集成之后，接着還要對系統進行確認驗證。 系統確認驗證需要以用戶為主體，以需求規格說明書中對軟件的定義為依據，由此對軟件 的各項規格進行逐項地確認，以確保已經完成的軟件系統與需求規格的一致性。為了方便用戶 在系統確認期間能夠積極參入，也為了系統在以后的運行過程中能夠被用戶正確使用，這個時期往往還需要以一定的方式對用戶進行必要的培訓。 在完成對軟件的驗收之后，軟件系統可以交付用戶使用，並需要以“項目開發總結報告” 的書面形式對項目進行總結。
3.軟件運行與維護期
軟件系統的運行是一個比較長久的過程，跟軟件開發機構有關的主要任務是對系統進行經常性的有效維護。 軟件的維護過程，也就是修正軟件錯誤，完善軟件功能，由此使軟件不斷進化升級的過程， 以使系統更加持久地滿足用戶的需要。因此，對軟件的維護也可以看成為對軟件的再一次開發。 在這個時期，對軟件的維護主要涉及三個方面的任務，即改正性維護、適應性維護和完善性維護。
二、瀑布模型
瀑布模型誕生於 20 世紀 70 年代，是最經典的並獲得最廣泛應用的軟件過程模型。圖 2-1 是傳統瀑布模型的圖樣表示。
瀑布模型中的“瀑布”是對這個模型的形象表達，即山頂傾瀉下來的水，自頂向下、逐層 細化。其中，自頂向下中的頂，可以理解為軟件項目初期對軟件問題的模糊認識，需要經過需求分析，才能使軟件問題逐步清晰，而獲得對軟件規格的明確定義，由此使軟件項目由定義期 過渡到開發期，並經過軟件開發而最終得到需要實現的軟件產品這個最底層結果。瀑布模型中 的逐層細化，其含義則是對軟件問題的不斷分解而使問題不斷具體化、細節化，以方便問題的解決。
1. 瀑布模型的特點
（1）線性化模型結構
瀑布模型所考慮的軟件項目是一種穩定的線性過程。項目被划分為從上至下按順序進行的 幾個階段，階段之間有固定的銜接次序，並且前一階段輸出的成果被作為后一階段的輸入條件。
（2）各階段具有里程碑特征
瀑布模型中的階段只能逐級到達，不能跨越。每個階段都有明確的任務，都需要產生出確 定的成果。
（3）基於文檔的驅動
文檔在瀑布模型中是每個階段的成果體現，因此，文檔也就成為了各個階段的里程碑標志。 由於后一階段工作的開展是建立在前一階段所產生的文檔基礎之上，因此，文檔也就成為了推動下一階段工作開展的前提動力。
（4）嚴格的階段評審機制
在某個階段的工作任務已經完成，並准備進入到下一個階段之前，需要針對這個階段的文 檔進行嚴格的評審，直到確認以后才能啟動下一階段的工作。
2. 瀑布模型的作用
瀑布模型是一種基於里程碑的階段過程模型，它所提供的里程碑式的工作流程，為軟件項目按規程管理提供了便利，例如，按階段制定項目計划，分階段進行成本核算，進行階段性評審等；並對提高軟件產品質量提供了有效保證。 瀑布模型的作用還體現在文檔上。每個階段都必須完成規定的文檔，並在每個階段結束前 都要對所完成的文檔進行評審。這種工作方式有利於軟件錯誤的盡早發現和盡早解決，並為軟件系統今后的維護帶來了很大的便利。 應該說，瀑布模型作為經典的軟件過程模型，為其他過程模型的推出提供了一個良好的拓 展平台。
3. 帶有信息反饋環的瀑布模型
在實際的軟件項目中存在着許多不穩定因素。例如，開發中的工作疏漏或通信誤解；在項目實施中途，用戶可能會提出一些新的要求；開發者也可能在設計中遇到某些未曾預料的實際困難，希望在需求中有所權衡等。 考慮到許多實際項目中階段之間有通信的需要，也就有了一種經過改進的，跟實際開發環 境更加接近的瀑布模型，如圖 2-2 所示。改進后的瀑布模型帶有信息反饋環，能夠逐級地將后續階段的意見返回，並在問題解決之后，再逐級地將修正結果下傳。
需要注意的是，為了確保文檔內容的一致性，信息反饋過程中任何有關影響文檔變更的行 為，只能在相鄰階段之間逐級地進行。
4. 瀑布模型的局限
瀑布模型是一種線性模型，要求項目嚴格按規程推進，必須等到所有開發工作全部作完以 后才能獲得可以交付的軟件產品。應該講，通過瀑布模型並不能對軟件系統進行快速創建，對 於一些急於交付的軟件系統的開發，瀑布模型有操作上的不便。 瀑布模型主要適合於需求明確，且無大的需求變更的軟件開發，例如，編譯系統、操作系統等。但是，對於那些分析初期需求模糊的項目，例如那些需要用戶共同參加需求定義的項目， 瀑布模型也有使用上的不便。
三、原型模型
1.快速原型的方法
快速原型方法是原型模型在軟件分析、設計階段的應用，用來解決用戶對軟件系統在需求 上的模糊認識，或用來試探某種設計是否能夠獲得預期結果。 快速原型方法具有以下一些特點：
（1）快速原型是用來獲取用戶需求的，或是用來試探設計是否有效的。一旦需求或設計確 定下來了，原型就將被拋棄。因此，快速原型要求快速構建、容易修改，以節約原型創建成本、 加快開發速度。快速原型往往采用一些快速生成工具創建，例如 4GL 語言。目前，Microsoft Visual Basic、Inprise Delphi 等基於組件的可視化開發工具，也被應用於原型創建之中，並 且都是非常有效的快速原型創建工具，而且還可用於原型進化。
（2）快速原型是暫時使用的，因此並不要求完整。它往往針對某個局部問題建立專門原型， 如界面原型、工作流原型、查詢原型等。 （3）快速原型不能貫穿軟件的整個生命周期，它需要和其他的過程模型相結合才能產生作 用。例如，在瀑布模型中應用快速原型，以解決瀑布模型在需求分析時期存在的不足。
2. 原型進化模型
原型進化對開發過程的考慮是，針對有待開發的軟件系統，先開發一個原型系統給用戶使用，然后根據用戶使用情況的意見反饋，對原型系統不斷修改，使它逐步接近並最終到達開發目標。跟快速原型不同的是，快速原型在完成需求定義后將被拋棄，而原型進化所要創建的原型則是一個今后將要投入應用的系統，只是所創建的原型系統在功能、性能等方面還有許多不 足，還沒有達到最終開發目標，需要不斷改進。 原型進化的工作流程如圖 2-3 所示。從圖中可以看到，它具有以下兩個特點：
（1）原型進化模型將軟件的需求細部定義、產品開發和有效性驗證放在同一個工作進程中 交替或並行運作。因此，在獲得了軟件需求框架以后，例如軟件的基本功能被確定以后，就可以直接進入到對軟件的開發中。
（2）原型進化模型是通過不斷發布新的軟件版本而使軟件逐步完善的，因此，這種開發模式特別適合於那些用戶急需的軟件產品開發。它能夠快速地向用戶交付可以投入實際運行的軟件成果，並能夠很好地適應軟件用戶對需求規格的變更。 原型進化模型能夠適應軟件需求的中途變更，但在應用的時候，以下問題需要得到足夠的 重視。
其一，原型進化模型雖說使開發進程加快了，但不能像瀑布模型那樣提供明確的里程碑管 理，隨着開發過程中版本的快速更新，項目管理、軟件配置管理會變得復雜起來，管理者難以把握開發進度。因此，對於大型軟件項目，原型進化模型缺乏有效的管理規程。
其二，開發過程中軟件版本的快速變更，還可能損傷軟件的內部結構，使其缺乏整體性和穩定性。另外，用於反映軟件版本變更的文檔也有可能跟不上軟件的變更速度。這些問題必將影響到今后軟件的維護。
3.增量模型
瀑布模型較難適應用戶的需求變更，開發速度慢。但是，瀑布模型提供了一套工程化的里程碑管理模式，能夠有效保證軟件質量，並使得軟件容易維護。 相反地，原型進化模型則可以使對軟件需求的詳細定義延遲到軟件實現時進行，並能夠使軟件開發進程加速。但是，原型進化模型不便於工業化流程管理，也不利於軟件結構的優化， 並可能使得軟件難以理解和維護。 基於以上因素的考慮，增量模型對這兩種模型的優點進行了結合。
1.增量模型的優點
增量模型是瀑布模型和原型進化模型的綜合，它對軟件過程的考慮是：在整體上按照瀑布模型的流程實施項目開發，以方便對項目的管理；但在軟件的實際創建中，則將軟件系統按功能分解為許多增量構件，並以構件為單位逐個地創建與交付，直到全部增量構件創建完畢，並都被集成到系統之中交付用戶使用。 如同原型進化模型一樣，增量模型逐步地向用戶交付軟件產品，但不同於原型進化模型的是，增量模型在開發過程中所交付的不是完整的新版軟件，而只是新增加的構件。 圖 2-4 是增量模型的工作流程，它被分成以下三個階段：
（1）在系統開發的前期階段，為了確保所建系統具有優良的結構，仍需要針對整個系統進行需求分析和概要設計，需要確定系統的基於增量構件的需求框架，並以需求框架中構件的組成及關系為依據，完成對軟件系統的體系結構設計。
（2）在完成軟件體系結構設計之后，可以進行增量構件的開發。這個時候，需要對構件進行需求細化，然后進行設計、編碼測試和有效性驗證。
（3）在完成了對某個增量構件的開發之后，需要將該構件集成到系統中去，並對已經發生 了改變的系統重新進行有效性驗證，然后再繼續下一個增量構件的開發。
2.增量模型的作用
增量模型帶來了以下幾方面的作用。
（1）開發初期的需求定義只是用來確定軟件的基本結構，這使得開發初期，用戶只需要對 軟件需求進行大概的描述，而對於需求的細節性描述，則可以延遲到增量構件開發時進行，以增量構件為單位逐個地進行需求補充。這種方式有利於用戶需求的逐漸明朗，能夠有效適應用戶需求的變更。
（2）軟件系統可以按照增量構件的功能安排開發的優先順序，並逐個實現和交付使用。這不僅有利於用戶盡早地用上系統，能夠更好地適應新的軟件環境，而且用戶在以增量方式使用 系統的過程中，還能夠獲得對軟件系統后續構件的需求經驗。這樣能使軟件需求定義越往后越 順利。
（3）軟件系統是逐漸擴展的，因此，開發者可以通過對諸多構件的開發，逐步積累開發經驗。實際上，增量式開發還有利於技術復用，前面構件中設計的算法、采用的技術策略、編寫的源碼等，都可以應用到后面將要創建的增量構件中去。
（4）增量式開發還有利於從總體上降低軟件項目的技術風險。個別的構件或許不能使用， 但這一般不會影響到整個系統的正常工作。 （5）實際上，在采用增量模型時，具有最高優先權的核心增量構件將會被最先交付，而隨着后續構件不斷被集成進系統，這個核心構件將會受到最多次數的測試。這意味着軟件系統最 重要的心臟部分將具有最高的可靠性，這將使得整個軟件系統更具健壯性。 可以說，比較瀑布模型、原型進化模型，增量模型具有非常顯著的優越性。但是，增量模型對軟件設計有更高的技術要求，特別是對軟件體系結構，要求它具有很好的開放性與穩定性， 能夠順利地實現構件的集成。在把每個新的構件集成到已建軟件系統的結構中的時候，一般要求這個新增的構件應該盡量少地改變原來已建的軟件結構。因此增量構件要求具有相當好的功能獨立性，其接口應該簡單，以方便集成時與系統的連接。
4.螺 旋 模 型
軟件開發過程中存在許多方面的風險。例如，軟件設計時遇到了很難克服的技術難題，軟件開發成本超出了先期預算，軟件產品不能按期交付，用戶對所交付的軟件不滿意等。應該說， 軟件風險是任何軟件項目中都普遍存在的實際問題，而且項目越大，軟件越復雜，風險也就越大。由於軟件風險可能在不同程度上損害軟件開發過程，並由此影響軟件產品質量，因此，在軟件開發過程中需要及時地識別風險、有效地分析風險，並能夠采取適當措施消除或減少風險的危害。
螺旋模型即是一種引入了風險分析與規避機制的過程模型，是瀑布模型、快速原型方法和 風險分析方法的有機結合。 螺旋模型基本方法是，在各個階段創建原型進行項目試驗，以降低各個階段可能遇到的項 目風險。例如，為了降低用戶對軟件界面不滿意的風險，可以在需求分析階段建立“界面原型”； 為了降低軟件不能按設計要求實現的風險，可以在設計階段針對所采用的技術建立“仿真試探 原型”。 圖 2-5 是螺旋模型的工作流程圖。它用螺旋線表示軟件項目的進行情況，其中，螺旋線中 的每個回路表示軟件過程的一個階段。因此，最里面的回路與項目可行性有關，接下來的一個 回路與軟件需求定義有關，而再下一個回路則與軟件系統設計有關，以此類推。
螺旋線中的每個回路都被分成為四個部分：
（1）目標設置：確定項目的階段性目標，分析項目風險。
（2）風險評估：對風險進行詳細地評估分析，並確定適當的風險規避措施。
（3）開發軟件：根據對風險的認識，決定采用合適的軟件開發模型，實施軟件開發。
（4）制定計划：對項目進行階段評審，制定項目下一個階段的工作計划。 對軟件項目進行風險分析也是需要費用的，假如項目風險分析費用過高，甚至超過項目開發費用，顯然這就不合算了。實際上，只有較大型的項目才有較高的風險，才有進行各個階段 詳細風險分析的必要。因此，螺旋模型主要應用於大型軟件項目之中。
5.噴泉模型
噴泉模型是專門針對面向對象軟件開發方法而提出的。“噴泉”一詞用於形象地表達面向對象軟件開發過程中的迭代和無縫過渡。 在面向對象方法中，對象既是對現實問題中實體的抽象，也是構造軟件系統的基本元素。 因此，建立對象模型在面向對象方法中，既可以用於分析，也可以用於設計，而且分析階段所獲得的對象框架模型可以無縫過渡到設計階段，以作為軟件實現的依據。 噴泉模型的過程方法所考慮的是，基於面向對象方法所帶來的便利，對軟件的分析、設計 和實現按照迭代的方式交替進行，並通過進化的方式，使軟件分階段逐漸完整、逐步求精。
例 如，
第一階段軟件開發的目標可以是軟件的基本功能；
第二階段可以是在第一階段建立的軟件 的基礎上，對軟件進行進一步的完善，並實現軟件的主要功能；
第三階段則是在第二階段的基 礎上，對軟件進行更加完整的開發，並以實現軟件全部功能作為創建目標。 應該說，噴泉模型能夠較有效地平衡軟件系統的近期需求與遠期規划，因此能夠較好地滿 足用戶在軟件應用上的發展需要。
6. 組件復用模型
自有軟件開發以來，軟件復用就一直存在，並產生了一些比較常用的軟件復用方法。傳統的軟件復用方法是建立源程序函數庫，可以把這些函數用在許多不同的軟件上面。而在面向對象技術中，軟件復用則可以通過建立類模塊來實現。由於大多數的類模塊具有繼承性，因此， 比起傳統方法，基於類模塊的復用效果要好一些。 組件復用方法是最近幾年才發展起來的更加先進的軟件復用技術，它能帶來更好的復用效果，並且更具有工程特性，更能適應軟件按工業流程生產的需求。 組件技術是基於面向對象技術發展起來的，可以把組件看作為 一個盒子，它里面封裝了許多個類模塊。因此，組件比類更大、更 抽象，其中包含了更多的功能，更具有通用性，更加有利於復用。 在基於組件復用的軟件開發中，軟件由組件裝配而成，這就如 同用標准零件裝配汽車一樣。圖 2-6 是組件復用模型的工作流程， 它以組件復用為驅動。 組件復用模型主要包含以下幾個階段的工作任務。
（1）需求框架描述：描述軟件系統功能構成，並將各項功能以設定的組件為單位進行區域划分。
（2）組件復用分析：按照需求框架中的組件成分，分析哪些組件是現成的，哪些組件可以在專業組件開發機構購買到，哪些組件不得不自己開發。
（3）需求修改與細化：以提高對現有組件的復用和降低新組件開發為目標，調整需求框架，並對已經確定的需求框架進行細化，由此獲得對軟件系統的詳細需求定義。
（4）系統設計：基於組件技術設計系統框架，設計需要開發的新組件。
（5）組件開發：開發不能獲得復用的新組件。
（6）系統集成：根據設計說明要求，將系統所需要的諸多組件整合在一起，構成一個完整的系統。 應該說，組件復用技術給軟件開發帶來了很多好處。它可以縮短開發周期、降低開發成本、 提高軟件質量、方便軟件維護，特別是可以使軟件生產按工業流程進行。 但值得注意的是，在組件復用中有可能會遇到組件復用率與用戶特殊需求之間的矛盾。例 如，開發機構希望使用現有的組件開發軟件以降低開發成本，但現有組件卻可能不能滿足用戶 的特殊需求。 另外，當采用組件復用技術實施軟件開發時，軟件中需要用到的組件往往是由一些專門的 軟件機構提供。也就是說，基於組件的軟件開發對外有很大的依賴性，顯然這不太利於軟件的 升級、改版。
小 結
1．軟件生命周期
如同任何事物都有一個發生、發展、成熟直至衰亡的全過程一樣，軟件系統或軟件產品也 有一個定義、開發、運行維護直至被淘汰這樣的全過程，我們把軟件將要經歷的這個全過程稱為軟件的生命周期。它包含：軟件定義、軟件開發、軟件運行維護三個時期，並可以細分為可行性研究、項目計划、需求分析、概要設計、詳細設計、編碼實現與單元測試、系統集成測試、 系統確認驗證、系統運行與維護等幾個階段。
2．瀑布模型
瀑布模型誕生於 20 世紀 70 年代，是最經典的並獲得最廣泛應用的軟件過程模型。瀑布模 型中的“瀑布”是對這個模型的形象表達，即山頂傾瀉下來的水，自頂向下、逐層細化。
（1）特點：線性化模型、階段具有里程碑特征、基於文檔的驅動、階段評審機制。
（2）作用：為軟件項目按規程管理提供了便利，為其他過程模型的推出提供了一個良好的拓展平台。
（3）局限性：主要適合於需求明確且無大的需求變更的軟件開發，但不適合分析初期需求模糊的項目。
3．原型模型
（1）快速原型方法：是原型模型在軟件分析、設計階段的應用，用來解決用戶對軟件系統 在需求上的模糊認識，或用來試探某種設計是否能夠獲得預期結果。
（2）原型進化模型：針對有待開發的軟件系統，先開發一個原型給用戶使用，然后根據用 戶的使用意見，對原型不斷修改，使它逐步接近，並最終到達開發目標。
4．增量模型
增量模型結合了瀑布模型與原型進化模型的優點。在整體上按照瀑布模型的流程實施開 發，以方便對項目的管理。但在軟件的實際創建中，則將軟件系統按功能分解為許多增量構件逐個地創建與交付，直到全部構件創建完畢，並都被集成到系統之中交付使用。 比較瀑布模型、原型進化模型，增量模型具有非常顯著的優越性。但增量模型對軟件設計有更高的技術要求。
5．螺旋模型
螺旋模型是一種引入了風險分析與規避機制的過程模型，是瀑布模型、快速原型方法和風險分析方法的有機結合。其基本方法是，在各個階段創建原型進行項目試驗，以降低各個階段可能遇到的項目風險。
6．噴泉模型
噴泉模型是專門針對面向對象軟件開發方法而提出的。“噴泉”一詞用於形象地表達面向 對象軟件開發過程中的迭代和無縫過渡。
7．組件復用模型
組件復用方法是最近幾年發展起來的先進的軟件復用技術，在基於組件復用的軟件開發 中，軟件由組件裝配而成，這就如同用標准零件裝配汽車一樣。因此，組件復用模型能夠有效 地提高軟件生產率。