教材作者的軟體工程的工具模型分幾層

『壹』 大學軟體工程專業教材都有哪些

1、《編譯原理》

教材:《編譯原理》, Alfred V. Aho, Jeffrey D.,ullman著,李建中,姜守旭 譯.

2、《解釋器構造》

教材:《編譯原理》, Alfred V. Aho, Jeffrey D.,ullman著,李建中,姜守旭 譯.

3、《計算機導論》

輔助教材：

《計算機文化》(New Perspective of Computer Science, 6th Edition)，電子工業出版社，(美)帕森斯(Parsons J.J)，2004

或《計算機文化》(New Perspective of Computer Science, 8th Edition), 電子工業出版社，(美)帕森斯(Parsons J.J)，2005

(1)教材作者的軟體工程的工具模型分幾層擴展閱讀：

軟體工程專業的主幹課程：

1、主幹學科：馬克思主義理論、大學外語、高等數學、大學物理、物理實驗、線性代數、概率論與數理統計、程序設計語言、數據結構、離散數學、操作系統、編譯技術、軟體工程概論、統一建模語言、軟體體系結構、軟體需求、軟體項目管理

2、該專業除了學習公共基礎課外，還將系統學習離散數學、數據結構、演算法分析、面向對象程序設計、現代操作系統、資料庫原理與實現技術、編譯原理、軟體工程、軟體項目管理、計算機安全等課程，根據學生的興趣還可以選修一些其它選修課。

3、實踐環節：畢業實習、課程設計、計算機工程實踐、生產實習、畢業設計。

參考資料來源：網路—軟體工程專業

『貳』 軟體工程中的cmm是什麼，有哪五個層次

CMM是指「能力成熟度模型」，其英文全稱為Capability Maturity Model for Software，英文縮寫為SW-CMM，簡稱CMM。它是對於軟體組織在定義、實施、度量、控制和改善其軟體過程的實踐中各個發展階段的描述。CMM的核心是把軟體開發視為一個過程，並根據這一原則對軟體開發和維護進行過程監控和研究，以使其更加科學化、標准化、使企業能夠更好地實現商業目標。

CMM是是一種用於評價軟體承包能力並幫助其改善軟體質量的方法，側重於軟體開發過程的管理及工程能力的提高與評估。CMM分為五個等級：一級為初始級，二級為可重復級，三級為已定義級，四級為已管理級，五級為優化級。

CMM是由美國卡內基梅隆大學軟體工程研究所1987年研製成功的，是目前國際上最流行最實用的軟體生產過程標准和軟體企業成熟度等級認證標准。目前，我國已有軟體企業通過了CMM標准認證 。

SW-CMM(Capability Maturity Model For Software 軟體生產能力成熟度模型,以下簡稱"CMM"),是87年由美國卡內基梅隆大學軟體工程研究所（CMU SEI）研究出的一種一種用於評價軟體承包商能力並幫助改善軟體質量的方法，其目的是幫助軟體企業對軟體工程過程進行管理和改進，增強開發與改進能力，從而能按時地、不超預算地開發出高質量的軟體。

其所依據的想法是：只要集中精力持續努力去建立有效的軟體工程過程的基礎結構，不斷進行管理的實踐和過程的改進，就可以克服軟體生產中的困難。CMM它是目前國際上最流行、最實用的一種軟體生產過程標准，已經得到了眾多國家以及國際軟體產業界的認可，成為當今企業從事規模軟體生產不可缺少的一項內容。

CMM目前通用流行的版本是1．1（Version1．1）。《按照軟體工程研究所（SEI）的原來計劃，CMM的改進版版本2．0（V2．0）是要在1997年的11月完成的。但是，美國國防部辦公室要求軟體工程研究所（SEI）延遲發放公布CMM版本2．0，直至他們完成另一個更為緊迫的項目-CMMI。

CMMI(Capability Maturity Model Integration能力成熟度模型集成)，是美國國防部的一個設想。他們希望把所有現存的與將被發展出來的各種能力成熟度模型，集成到一個框架中去。這個框架用於解決兩個問題：第一，軟體獲取辦法的改革；第二，從集成產品與過程發展的角度出發,建立一種包含健全的系統開發原則的過程改進。

CMM為軟體企業的過程能力提供了一個階梯式的改進框架，它基於過去所有軟體工程過程改進的成果，吸取了以往軟體工程的經驗教訓，提供了一個基於過程改進的框架；它指明了一個軟體組織在軟體開發方面需要管理哪些主要工作、這些工作之間的關系、以及以怎樣的先後次序，一步一步的做好這些工作而使軟體組織走向成熟。

一、CMM的誕生

信息時代，軟體質量的重要性越來越為人們所認識。軟體是產品、是裝備、是工具，其質量使得顧客滿意，是產品市場開拓、事業得以發展的關鍵。而軟體工程領域在1992年至1997年取得了前所未有的進展,其成果超過軟體工程領域過去15年來的成就總和。

軟體管理工程引起廣泛注意源於20世紀70年代中期。當時美國國防部曾立題專門研究軟體項目做不好的原因，發現70%的項目是因為管理不善而引起，而並不是因為技術實力不夠，進而得出一個結論，即管理是影響軟體研發項目全局的因素，而技術隻影響局部。到了20世紀90年代中期，軟體管理工程不善的問題仍然存在，大約只有10%的項目能夠在預定的費用和進度下交付。軟體項目失敗的主要原因有：需求定義不明確；缺乏一個好的軟體開發過程；沒有一個統一領導的產品研發小組；子合同管理不嚴格；沒有經常注意改善軟體過程；對軟體構架很不重視；軟體界面定義不善且缺乏合適的控制；軟體升級暴露了硬體的缺點；關心創新而不關心費用和風險；軍用標准太少且不夠完善等等。在關繫到軟體項目成功與否的眾多因素中，軟體度量、工作量估計、項目規劃、進展控制、需求變化和風險管理等都是與工程管理直接相關的因素。由此可見，軟體管理工程的意義至關重要。

軟體管理工程和其它工程管理相比有其特殊性。首先，軟體是知識產品，進度和質量都難以度量，生產效率也難以保證。其次，軟體系統復雜程度也是超乎想像的。因為軟體復雜和難以度量，軟體管理工程的發展還很不成熟。

軟體管理工程的發展，在經歷了從70年代開始以結構化分析與設計、結構化評審、結構化程序設計以及結構化測試為特徵的結構化生產時代，到90年代中期，以CMM模型的成熟模型和日益為市場接受為標志，已經進入以過程成熟模型CMM、個體軟體過程PSP和群組軟體過程TSP為標志的以過程為中心的時代，而軟體發展第三個時代，及軟體工業化生產時代，從90年代中期軟體過程技術的成熟和面向對象技術、構件技術的發展為基礎，已經漸露端倪，估計到2005年，可以實現真正的軟體工業化生產，這個趨勢應該引起軟體企業界和有關部門的高度重視，及早採取措施，跟上世界軟體發展的腳步。軟體生產轉向以改善軟體過程為中心，是世界各國軟體產業或遲或早都要走的道路。

軟體過程改善是當前軟體管理工程的核心問題。50多年來計算事業的發展使人們認識到要高效率、高質量和低成本地開發軟體，必須改善軟體生產過程。軟體管理工程走過了一條從70年代開始以結構化分析與設計、結構化評審、結構化程序設計以及結構化測試到90年代中期以過程成熟模型CMM、個體軟體過程PSP和群組軟體過程TSP為標志的以過程為中心向著軟體過程技術的成熟和面向對象技術、構件技術的發展為基礎的真正軟體工業化生產的道路。軟體生產轉向以改善軟體過程為中心，是世界各國軟體產業或遲或早都要走的道路。軟體工業已經或正在經歷著"軟體過程的成熟化"，並向"軟體的工業化"漸進過渡。規范的軟體過程是軟體工業化的必要條件。

軟體過程研究的是如何將人員、技術和工具等組織起來，通過有效的管理手段，提高軟體生產的效率，保證軟體產品的質量。由此誕生了軟體過程的三個流派：CMU-SEI的CMM/PSP/TSP；ISO 9000質量標准體系；ISO/IEC 15504（SPICE）。

CMM/PSP/TSP即軟體能力成熟度模型/ 個體軟體過程/群組軟體過程，是1987年美國 Carnegie Mellon 大學軟體工程研究所(CMU/SEI)以W.S.Humphrey為首的研究組發表的研究成果"承製方軟體工程能力的評估方法"；SO 9000質量標准體系是在70年代由歐洲首先採用的，其後在美國和世界其他地區也迅速地發展起來。目前，歐洲聯合會積極促進軟體質量的制度化，提出了如下ISO9000軟體標准系列：ISO9001、ISO9000-3、ISO9004-2、ISO9004-4、ISO9002；ISO/IEC 15504（SPICE）是1991年國際標准化組織採納了一項動議，開展調查研究，按照CMU-SEI的基本思路，產生的技術報告ISO/IEC 15504--信息技術軟體過程評估

目前，學術界和工業界公認美國 Carnegie Mellon 大學軟體工程研究所(CMU/SEI) 以W.S.Humphrey為首主持研究與開發的軟體能力成熟度模型CMM是當前最好的軟體過程，已成為業界事實上的軟體過程的工業標准。

二、CMM的發展

1987年美國 Carnegie Mellon 大學軟體工程研究所(CMU/SEI)以W.S.Humphrey為首的研究組發表了CMM/PSP/TSP 技術，為軟體管理工程開辟了一條新的途經。

CMM框架用5個不斷進化的層次來評定軟體生產的歷史與現狀：其中初始層是混沌的過程，可重復層是經過訓練的軟體過程，定義層是標准一致的軟體過程，管理層是可預測的軟體過程，優化層是能持續改善的軟體過程。任何單位所實施的軟體過程，都可能在某一方面比較成熟，在另一方面不夠成熟，但總體上必然屬於這5個層次中的某一個層次。而在某個層次內部，也有成熟程度的區別。在CMM框架的不同層次中，需要解決帶有不同層次特徵的軟體過程問題。因此，一個軟體開發單位首先需要了解自己正處於哪一個層次，然後才能夠對症下葯地針對該層次的特殊要求解決相關問題，這樣才能收到事半功倍的軟體過程改善效果。任何軟體開發單位在致力於軟體過程改善時，只能由所處的層次向緊鄰的上一層次進化。而且在由某一成熟層次向上一更成熟層次進化時，在原有層次中的那些已經具備的能力還必須得到保持與發揚。

軟體產品質量在很大程度上取決於構築軟體時所使用的軟體開發和維護過程的質量。軟體過程是人員密集和設計密集的作業過程：若缺乏有素訓練，就難以建立起支持實現成功是軟體過程的基礎，改進工作亦將難以取得成效。CMM描述的這個框架正是勾列出從無定規的混沌過程向訓練有素的成熟過程演進的途徑。

CMM包括兩部分"軟體能力成熟度模型"和"能力成熟度模型的關鍵慣例"。"軟體能力成熟度模型"主要是描述此模型的結構，並且給出該模型的基本構件的定義。"能力成熟度模型的關鍵慣例"詳細描述了每個"關鍵過程方面"涉及的"關鍵慣例"。這里"關鍵過程方面"是指一組相關聯的活動；每個軟體能力成熟度等級包含若干個對該成熟度等級至關重要的過程方面，它們的實施對達到該成熟度等級的目標起到保證作用。這些過程域就稱為該成熟度等級的關鍵過程域，反之有非關鍵過程域是指對達到相應軟體成熟度等級的目標不起關鍵作用。歸納為：互相關聯的若干軟體實踐活動和有關基礎設施的一個集合。而"關鍵慣例"是指使關鍵過程方面得以有效實現和制度化的作用最大的基礎設施和活動,對關鍵過程的實踐起關鍵作用的方針、規程、措施、活動以及相關基礎設施的建立。關鍵實踐一般只描述"做什麼"而不強制規定"如何做"。各個關鍵慣例按每個關鍵過程方面的5個"公共特性"（對執行該過程的承諾，執行該過程的能力，該過程中要執行的活動，對該過程執行情況的度量和分析，及證實所執行的活動符合該過程）歸類，逐一詳細描述。當作到了某個關鍵過程的的全部關鍵慣例就認為實現了該關鍵過程，實現了某成熟度級及其以低級所含的全部關鍵過程就認為達到到了了該級。

上面提到了CMM把軟體開發組織的能力成熟度分為5個的等級。除了第1級外，其他每一級由幾個關鍵過程方面組成。每一個關鍵過程方面都由上述5種公共特性予以表徵。CMM給每個關鍵過程了一些具體目標。按每個公共特性歸類的關鍵慣例是按該關鍵過程的具體目標選擇和確定的。如果恰當地處理了某個關鍵過程涉及的全部關鍵慣例，這個關鍵過程的各項目標就達到了，也就表明該關鍵過程實現了。這種成熟度分級的優點在於，這些級別明確而清楚地反映了過程改進活動的輕重緩急和先後順序。

『叄』 誰能給我推薦幾本軟體工程的書

visual C++.NET編程實例，蘇峰，黃金雙，湯蕾編著，清華大學出版社，2004年1月，北京
visual C++。NET基礎教程與上機指導，計算機職業教育聯盟主編，清華大學出版社，2005年3月，北京
1、《機械工業協會 》 出版社：機械工業
2、《軟體估算——「黑匣子」揭秘 》
本書中，著名的軟體開發書籍的作者Steve McConnell揭開了圍繞在軟體估算周圍的層層迷霧。作者在深入淺出地介紹了與軟體估算有關的主要概念之後，深入、全面地介紹了與軟體估算有關的多種估算方法。本書的主要內容包括：估算與計劃和項目控制，以及估算與目標和承諾之間的關系；不確定性錐與估算中的誤差來源以及影響估算的各種因素；先計數、再計算，無法可想時才依靠判斷的基本估算原則；用於估算軟體項目的三個重要部分——規模、工作量和進度估算的基本方法；與規模、工作量和進度估算有關的特殊問題；估算的概率論觀點以及如何採用適當的方式來表達估算結果中的不確定性；如何進行與估算有關的溝通，從而使技術人員和非技術人員達成共識。本書主要面向軟體開發項目中要進行估算的開發人員和技術管理人員。但本書所涉及的與軟體估算有關的背景知識，以及有關估算談判和表達方式的討論，對於非技術人員出身的主管和項目的其他有關人員同樣大有裨益。
3、《軟體設計精要與模式》——張逸 著
「給我一個支點，我就能撬起地球」。關鍵不在於力量有多大，而在於如何合理地利用力量。軟體設計同樣如此。思想的確立，技巧的把握，將在很大程度上決定軟體架構的合理性。基於這樣的目的，本書圍繞著軟體設計的核心內容，結合大量的實例與代碼，充分地展示了軟體設計之美，以及設計「力量」的巧妙運用。內容涵蓋了設計模式、重構、測試驅動開發、極限編程、軟體體系架構設計等重要的設計方法與技巧。這些內容是軟體設計中最重要的「流行元素」，是程序員向設計師「涅磐」的基石，是從小工到專家的修煉法門。
本書關注的焦點是軟體設計，涵蓋了大部分與設計有關的基本要素，包括面向對象編程思想、設計模式、重構、測試驅動開發、極限編程以及軟體體系架構設計。其中，尤以設計模式為主，深入探討了軟體設計過程中的原則與模式，並結合大量的實例與代碼演示了如何合理運用設計模式，改善程序模塊的可復用性、可擴展性，實現模塊間的鬆散耦合。全書將軟體設計理論與項目實踐完美地結合起來，使其告別了純理論研究的空泛，具有現實的指導意義。本書共分為5篇，包括：設計之要、.NET Framework與設計模式、媒體播放器的設計之旅、設計模式應用實踐以及.NET體系架構設計。本書力求講解淺顯明白。在技術探討上，盡可能地深入透徹；在每一字的描述上，盡可能地簡單易懂。本書適用於所有希望提高軟體設計水平的程序員、軟體工程師，同時，對於軟體設計師與系統架構師也具有一定的參考價值。
4、《SOA 原理·方法·實踐》——毛新生 主編

本書並不是關於Web服務的又一本開發手冊，抑或是開發技術的寶典之類的讀物。本書的作者來自於IBM軟體開發中心的SOA技術中心，作為最早的一批從事SOA相關產品和客戶項目開發的軟體技術人員，見證了SOA從誕生到發展壯大的全過程。而本書的目的在於將作者在項目過程中的經驗介紹給讀者，通過分析SOA產生的根源，以及SOA對業務模式和開發模式帶來的變革，幫助讀者理解什麼是SOA，以及如何科學的實施SOA。本書的內容分為三部分，將從作者的實際經驗出發，分析SOA理念產生的合理性，然後分析SOA的相關開發技術，最後結合一個實例片斷，講述一個完整的SOA項目是如何設計完成的。
本書針對的讀者是有一定經驗的開發人員，例如，信息系統架構師，企業決策人員，對Web開發感興趣的高年級計算機或相關領域的學生，以及任何希望了解SOA的廣大技術人員。
現任IBM中國開發中心Web 2.0首席架構師，此前他曾任IBM軟體集團企業解決方案部大中華區和北亞地區首席架構師與IBM SOA中國設計中心技術主管，在企業級軟體方面擁有廣泛、扎實、深厚的理論功底和豐富的設計與項目實施經驗。
5、《軟體架構設計》——溫昱 著
本書緊緊圍繞「軟體架構設計」這一主題，立足實踐解析了軟體架構的概念，闡述了切實可行的軟體架構設計方法，提供了可操作性極強的完整的架構設計過程。另外，本書從思維方式的突破、面向對象設計、UML建模、過程與管理等關鍵過渡環節，為廣大程序員的成長提供了切中肯綮的指導。
6、《大道至簡——軟體工程實踐者的思考》
本書是在「思想方法學」這一軟體工程尚未涉足過的領域中的實習之作。作者親歷國內軟體工程的英雄時代、泡沫時代，從失敗中醒覺而創建獨特的思考方法，對軟體開發、工程中的現狀深刻反思，從而完成這本專著。在缺乏獨立思維、對國外工程理論亦步亦趨的國內工程界、開發業界，該書無疑是一份激盪新思的佳作。本書是第一本討論軟體工程思想本源的書籍，也是第一本從工程實踐出發溯源而論的佳作。
本書提出了審視軟體工程的全新視角和軟體工程的體系模型（EHM，軟體工程層狀模型）用非工程的方式重新解析軟體工程現象，全面、細致而深刻地分析了工程中各個環節的由來、價值及其內在關系。
計算機軟體技術基礎
清華大學出版社; 第3版 (2000年7月1日)
沈被娜
《計算機軟體技術基礎》(第3版)內容包括數據結構、操作系統、資料庫系統、計算機網路、軟體工程及管理信息系統等共8章。每章有基本原理敘述和常用實例介紹，各章後附有習題。
學軟體工程的，首先得會編程，軟體工程裡面的內容很多，就測試這一項就有很多知識：性能測試，功能測試，寫測試報告。你要是要學基礎的軟體工程知識，那就看大學的課本--《軟體工程》，如果是想搞測試那麼還得看IBM的軟體測試的性能測試和功能測試。自己到網站下載吧。

『肆』 軟體工程分為那幾個階段

軟體工程是用工程方法研製和維護軟體的過程和有關技術。軟體研製的四個階段包括需求分析、設計、實現和測試；軟體維護指的是使用過程中對已有軟體的修改和完善。軟體工程的主要對象是大型軟體，它覆蓋了軟體開發技術、軟體工程環境、軟體經濟學、軟體心理學，以及軟體工程管理等多方面的內容。它研究的問題主要有：質量保證和質量評價，研製和維護的方法、軟體工具系統、文件、用戶界面的設計，軟體管理等。軟體工程的最終目的是，擺脫手工生產軟體的狀況，實現軟體研製和維護的自動化。

『伍』 軟體工程軟體開發v模型有哪些基本劃分

V模型是對瀑布模型的修正，強調了驗證活動，由Paul Rook在1980年率先提出。在瀑布模型中，由於早期的錯誤可能要等到開發後期的測試階段才能發現，所以可能帶來嚴重的後果。V模型就是在這點上改進了瀑布模型，即在軟體開發的生存期中，開發活動和測試活動幾乎同時開始，這兩個並行的動態的過程就會極大地減小bug和error出現的概率。V模型是瀑布模型的變種，它反映了測試活動與分析和設計的關系

『陸』 軟體工程 有哪兩種主要的分析模型，各有哪些工具支持

1問題定義

問題定義階段必須回答的關鍵問題：「要解決的問題是什麼？」如果不知道問題是什麼就試圖解決這個問題，顯然是盲目的，只會白白浪費時間和金錢，最終得出的結果很可能是毫無意義的。盡管確切地定義問題的必要性是十分明顯的，但是在實踐中它卻可能是最容易被忽視的一個步驟。

通過問題定義階段的工作，系統分析員應該提出關於問題性質、工程目標和規模的書面報告。通過對系統的實際用戶和使用部門負責人的訪問調查，分析員扼要地寫出他對問題的理解，並在用戶和使用部門負責人的會議上認真討論這份書面報告，澄清含糊不精的地方，改正理解不正確的地方，最後得出一份雙方都滿意的文檔。

『柒』 TCP/IP協議參考模型共分為了幾層，其中3、4層分別是什麼

TCP/IP協議參考模型共有4層，從下到上3、4層分別是網路層、網路介面層。

分別介紹TCP/IP協議中的四個層次：

1、應用層：應用層是TCP/IP協議的第一層，是直接為應用進程提供服務的。

2、運輸層：作為TCP/IP協議的第二層，運輸層在整個TCP/IP協議中起到了中流砥柱的作用。且在運輸層中，TCP和UDP也同樣起到了中流砥柱的作用。

3、網路層：網路層在TCP/IP協議中的位於第三層。在TCP/IP協議中網路層可以進行網路連接的建立和終止以及IP地址的尋找等功能。

4、網路介面層：在TCP/IP協議中，網路介面層位於第四層。由於網路介面層兼並了物理層和數據鏈路層所以，網路介面層既是傳輸數據的物理媒介，也可以為網路層提供一條准確無誤的線路。

(7)教材作者的軟體工程的工具模型分幾層擴展閱讀

OSI模型：

1、第1層是物理層（Physical Layer)（也即OSI模型中的第一層）

2、第2層是數據鏈路層(Data Link Layer)運行乙太網等協議。

3、第3層是網路層(Network Layer)在計算機網路中進行通信的兩個計算機之間可能會經過很多個數據鏈路，也可能還要經過很多通信子網。

4、第4層是處理信息的傳輸層(Transport Layer)。第4層的數據單元也稱作數據包（packets）。但是，當你談論TCP等具體的協議時又有特殊的叫法，TCP的數據單元稱為段（segments）而UDP協議的數據單元稱為「數據報（datagrams）」。

5、第5層是會話層( Session Layer)這一層也可以稱為會晤層或對話層，在會話層及以上的高層次中，數據傳送的單位不再另外命名，統稱為報文。

6、第6層是表示層(Presentation Layer)這一層主要解決用戶信息的語法表示問題。

7、第7層是「一切」。第7層也稱作「應用層」(Application Layer)，是專門用於應用程序的。

『捌』 軟體工程層次化結構分幾層

一計劃時期
1.問題定義(要解決的問題是什麼？)
2.可行性研究（對於問題有解決方法嗎？）
二開發時期
1.需求分析（為了解決問題，目標系統必須做什麼？）
2.概要設計（怎樣實現目標系統？）
3.詳細設計（怎樣具體實現這個系統？）
4.編碼
5.測試
三運行時期
運行時期的主要工作是維護

『玖』 軟體開發模型有哪幾種各有什麼特點

軟體開發模型(Software Development Model)是指軟體開發全部過程、活動和任務的結構框架。軟體開發包括需求、設計、編碼和測試等階段，有時也包括維護階段。軟體開發模型能清晰、直觀地表達軟體開發全過程，明確規定了要完成的主要活動和任務，用來作為軟體項目工作的基礎。對於不同的軟體系統，可以採用不同的開發方法、使用不同的程序設計語言以及各種不同技能的人員參與工作、運用不同的管理方法和手段等，以及允許採用不同的軟體工具和不同的軟體工程環境。軟體工程的主要環節包括人員管理、項目管理、需求分析、系統設計、程序設計、測試、維護等，如圖所示。軟體開發模型是對軟體過程的建模，即用一定的流程將各個環節連接起來，並可用規范的方式操作全過程，好比工廠的生產線。

8.混合模型（hybrid model）過程開發模型又叫混合模型（hybrid model），或元模型（meta-model）,把幾種不同模型組合成一種混合模型，它允許一個項目能沿著最有效的路徑發展，這就是過程開發模型（或混合模型）。實際上，一些軟體開發單位都是使用幾種不同的開發方法組成他們自己的混合模型。各種模型的比較每個軟體開發組織應該選擇適合於該組織的軟體開發模型，並且應該隨著當前正在開發的特定產品特性而變化，以減小所選模型的缺點，充分利用其優點，下表列出了幾種常見模型的優缺點。各種模型的優點和缺點：模型優點缺點瀑布模型文檔驅動系統可能不滿足客戶的需求快速原型模型關注滿足客戶需求可能導致系統設計差、效率低，難於維護增量模型開發早期反饋及時，易於維護需要開放式體系結構，可能會設計差、效率低螺旋模型風險驅動風險分析人員需要有經驗且經過充分訓練

9.RUP模型（迭代模型）

RUP（Rational Unified Process）模型是Rational公司提出的一套開發過程模型，它是一個面向對象軟體工程的通用業務流程。它描述了一系列相關的軟體工程流程，它們具有相同的結構，即相同的流程構架。RUP 為在開發組織中分配任務和職責提供了一種規范方法，其目標是確保在可預計的時間安排和預算內開發出滿足最終用戶需求的高品質的軟體。RUP具有兩個軸，一個軸是時間軸，這是動態的。另一個軸是工作流軸，這是靜態的。在時間軸上，RUP劃分了四個階段：初始階段、細化階段、構造階段和發布階段。每個階段都使用了迭代的概念。在工作流軸上，RUP設計了六個核心工作流程和三個核心支撐工作流程，核心工作流軸包括：業務建模工作流、需求工作流、分析設計工作流、實現工作流、測試工作流和發布工作流。核心支撐工作流包括：環境工作流、項目管理工作流和配置與變更管理工作流。RUP 匯集現代軟體開發中多方面的最佳經驗，並為適應各種項目及組織的需要提供了靈活的形式。作為一個商業模型，它具有非常詳細的過程指導和模板。但是同樣由於該模型比較復雜，因此在模型的掌握上需要花費比較大的成本。尤其對項目管理者提出了比較高的要求。它具有如下特點：（1）增量迭代，每次迭代都遵循瀑布模型能夠在前期控制好和解決風險；（2）模型的復雜化，需要項目管理者具有較強的管理能力。

10.IPD模型

IPD（Integrated Proct Development）流程是由IBM提出來的一套集成產品開發流程，非常適合於復雜的大型開發項目，尤其涉及到軟硬體結合的項目。

IPD從整個產品角度出發，流程綜合考慮了從系統工程、研發（硬體、軟體、結構工業設計、測試、資料開發等）、製造、財務到市場、采購、技術支援等所有流程。是一個端到端的流程。在IPD流程中總共劃分了六個階段（概念階段、計劃階段、開發階段、驗證階段、發布階段和生命周期階段），四個個決策評審點（概念階段決策評審點、計劃階段決策評審點、可獲得性決策評審點和生命周期終止決策評審點）以及六個技術評審點。

IPD流程是一個階段性模型，具有瀑布模型的影子。該模型通過使用全面而又復雜的流程來把一個龐大而又復雜的系統進行分解並降低風險。一定程度上，該模型是通過流程成本來提高整個產品的質量並獲得市場的佔有。由於該流程沒有定義如何進行流程回退的機制，因此對於需求經常變動的項目該流程就顯得不大適合了。並且對於一些小的項目，也不是非常適合使用該流程。