第01章 軟件工程學概述

軟件工程

SoftwareEngineering

主講人：李傳斌郵箱：li_chuan_bin@163.com電話件工程是開發(fā)、運行、維護和修復軟件的系統(tǒng)方法處在十字路口的中國軟件產(chǎn)業(yè)主權大國必須建立基于自主技術的、完整的軟件產(chǎn)業(yè)體系。

軟件本國提供率：中國1/3左右，美國97%“印度模式”還是“中國模式”英語語言能力、素質(zhì)教育（邏輯思維、態(tài)度、溝通、團隊等）、人才層次結構、職業(yè)教育（50萬/年，大學7.4萬）、產(chǎn)學研相結合軟件人才結構不合理，缺乏中高級軟件人才；軟件人員缺乏軟件工程化的概念。課程介紹及要求用工程化的方法來開發(fā)軟件教學目標為什么要學習這門課程有助于正確理解和認識“軟件”的概念及其特點理解軟件開發(fā)面臨的問題和挑戰(zhàn)掌握軟件工程的原則、方法，系統(tǒng)地開發(fā)軟件，尤其是復雜、大型的軟件的開發(fā)了解和接觸軟件開發(fā)所需的各種技術手段學習三部曲：理解、掌握和運用理解什么是軟件工程為什么需要軟件工程(產(chǎn)生背景)軟件工程需要解決哪些問題軟件工程涉及哪些方面內(nèi)容掌握軟件工程概念過程技術工具運用運用工程化思想進行軟件開發(fā)需求分析軟件設計程序設計軟件維護程序設計語言最好有一定的軟件開發(fā)經(jīng)驗先導要求：學習要求學理解課本的知識點和思想，無需死記硬背閱讀相關課外資料做（紙上得來終覺淺，絕知此事要躬行）實踐體會軟件工程的原則、方法和技術，在實踐中提高培養(yǎng)抽象思維能力培養(yǎng)獨立解決問題的能力培養(yǎng)合作精神思融會貫通10參考文獻軟件工程導論（第五版），張海藩，清華大學出版社軟件工程實踐導論--有關方法、設計、實現(xiàn)、管理之三十六計，金尊和，清華大學出版社，2005.軟件開發(fā)的科學與藝術，微軟亞洲研究院，電子工業(yè)出版社，2002

年

軟件工程－實踐者的研究方法，RS.Pressman,機械工業(yè)出版社現(xiàn)代軟件工程,周之英編著,科學出版社現(xiàn)代軟件工程,張家浩，機械工業(yè)出版社軟件工程案例教程，韓萬江，機械工業(yè)出版社Internet上的各類學習網(wǎng)站…第1章軟件工程概述軟件工程產(chǎn)生的背景(軟件危機)軟件工程定義軟件工程方法學軟件過程模型小結1.1軟件工程產(chǎn)生的背景軟件

a.軟件的定義

軟件(Software)是計算機系統(tǒng)中與硬件相互依存的另一部分，它是包括程序(Program)

，數(shù)據(jù)(Data)及其相關文檔(Document)的完整集合。Software=Program+Data+Document程序是按事先設計的功能和性能要求執(zhí)行的指令序列數(shù)據(jù)是使程序能正常操縱信息的數(shù)據(jù)結構文檔是與程序開發(fā)，維護和使用有關的圖文材料13非常復雜邏輯復雜遠遠高于硬件的邏輯復雜度開發(fā)復雜成本難以估算進度難以控制人員素質(zhì)要求高質(zhì)量得不到保證96年Ariane火箭發(fā)射失敗，原因是浮點數(shù)轉換時發(fā)生錯誤；浮點運算誤差導致美國愛國者導彈攔截敵方導彈失敗導致己方死傷多人；數(shù)值溢出導致歐洲昂貴的火箭發(fā)射失敗。1.1軟件工程產(chǎn)生的背景1)軟件b.軟件的特征成本高1.1軟件工程產(chǎn)生的背景

1)軟件b.軟件的特征風險大1995年美國Standish咨詢集團的統(tǒng)計分析(至90年代初的軟件項目執(zhí)行情況)成功：16.2%失?。?1％受到挑戰(zhàn)：53.8%近幾年來的統(tǒng)計數(shù)據(jù)成功：26％失?。?8％受到挑戰(zhàn)：46%1.1軟件工程產(chǎn)生的背景

1)軟件b.軟件的特征維護困難維護形式多樣化改正性：修復故障完善性：增加功能適應性：移植維護成本越來越高55%到70％維護帶來的問題多1.1軟件工程產(chǎn)生的背景

1)軟件

b.軟件的特征1.1軟件工程產(chǎn)生的背景c.軟件的發(fā)展早期面向批處理有限的分布自定義軟件第二階段多用戶實時數(shù)據(jù)庫軟件產(chǎn)品第三階段分布式系統(tǒng)嵌入“智能”低成本硬件消費者的影響第四階段強大的桌面系統(tǒng)面向對象技術專家系統(tǒng)人工神經(jīng)網(wǎng)絡并行計算網(wǎng)絡計算機1950196019701980199020001968年10月，北大西洋公約組織（NATO）的科學家FeitzBauer在德國Garmish召開的學術會議上正式提出了軟件危機問題。1.1軟件工程產(chǎn)生的背景2)軟件危機a.軟件危機的表現(xiàn)（1/3）

成本高IBM360OS,5000多人年，耗時4年(1963－1966)，花費2億多美元美國空軍：1955年軟件占總費用(計算機系統(tǒng))的18%，70年60%，85年達到85％美國全球軍事指揮控制系統(tǒng)，硬件1億美元，軟件高達7.2億美元計算機軟件和硬件費用比軟件質(zhì)量得不到保證軟件應用面的擴大：科學計算、軍事、航空航天、工業(yè)控制、企業(yè)管理、辦公、家庭軟件越來越多的應用于安全攸關(safetycritical)的系統(tǒng)，對軟件質(zhì)量提出更高的要求80年代歐洲亞麗安娜火箭的發(fā)射失敗，原因是軟件錯誤美國阿托拉斯火箭的發(fā)射失敗，原因是軟件故障英國1986年開發(fā)的辦公室信息系統(tǒng)Folios經(jīng)4年，因性能達不到要求，1989年取消日本第5代機因為軟件問題在投入50億美元后于1993年下馬由于軟件質(zhì)量問題導致失敗的軟件項目非常多a.軟件危機的表現(xiàn)（2/3）a.軟件危機的表現(xiàn)（3/3）進度難以控制項目延期比比皆是由于進度問題而取消的軟件項目較常見只有一小部分的項目能夠按期完成維護非常困難軟件維護的多樣性軟件維護的復雜性軟件維護的副作用軟件危機主要表現(xiàn)形式對軟件開發(fā)成本和研制進度的估計常常很不精確“已完成”的軟件不能滿足用戶要求軟件產(chǎn)品質(zhì)量差，可靠性得不到保證軟件產(chǎn)品可維護性差，沒有統(tǒng)一、公認的規(guī)范和完整規(guī)范的文檔軟件成本在計算機系統(tǒng)總成本中所占的比例逐年上升軟件開發(fā)生產(chǎn)率提高的速度，遠遠跟不上計算機應用速度普及深入的趨勢b.產(chǎn)生軟件危機的原因與軟件本身的特點有關(難于維護,邏輯復雜)與軟件開發(fā)與維護的方法不正確有關:軟件≠程序急于求成=拔苗助長各自為陣、無方法學(1)軟件開發(fā)和維護的不正確方法主要表現(xiàn)為忽視軟件開發(fā)前期的需求分析(2)開發(fā)過程沒有統(tǒng)一的、規(guī)范的方法論的指導，文件資料不齊全，忽視人與人的交流(3)忽視測試階段的工作，提交用戶的軟件質(zhì)量差(4)輕視軟件的維護開發(fā)一個具有一定規(guī)模和復雜性的軟件系統(tǒng)與編寫一個簡單的程序不一樣正如搭建茅草房和建設高樓大廈大型、復雜軟件系統(tǒng)的開發(fā)是一項工程，必須按照工程化的方法組織軟件的生產(chǎn)和管理，必須經(jīng)過分析、設計、實現(xiàn)、測試、維護等一系列軟件過程和活動c.軟件工程（學）因危機而產(chǎn)生d.軟件工程(學):克服軟件危機的努力（1）從管理的角度

軟件開發(fā)過程的研究、文檔的標準化以及人們

的交流方式等（2）軟件開發(fā)方法的研究

結構化軟件開發(fā)方法,面向對象的開發(fā)方法提出有效的方法和工具支持軟件開發(fā)1968年提出軟件工程概念和思想20世紀70年代的結構化軟件開發(fā)方法20世紀80年代的面向對象的軟件開發(fā)方法新的技術:軟件重用、快速原型、需求工程典型技術:COM,Java,C++,J2EE,.Net,….支撐工具和環(huán)境：Jbuilder,VisualStudio,WebLogic,…1、解決危機的技術途徑20世紀80年代末，美國DoD和工業(yè)界開始認識到管理的重要性美國DoD的一項研究表明，70%的項目由于管理不善導致難以控制進度、成本和質(zhì)量；進一步的研究發(fā)現(xiàn)：管理是影響軟件項目成功開發(fā)的全局性因素，而技術只影響局部如果軟件開發(fā)組織不能對軟件項目進行有效管理，就不能充分發(fā)揮軟件開發(fā)方法和工具的潛力，也就不能高效率地開發(fā)出高質(zhì)量的軟件產(chǎn)品。2、解決危機的管理途徑總結：解決軟件危機途徑首先應該對計算機軟件有一個正確的認識，徹底清除“軟件就是程序”的錯誤觀念。要使用并且不斷研究探索更好、更有效的技術和方法要有良好的組織、嚴密的管理應該開發(fā)和使用好的軟件工具1.2軟件工程定義(1)Theestablishmentanduseofsoundengineeringprinciples(methods)inordertoobtaineconomicallysoftwarethatisreliableandworksonrealmachines.(1968-FritzBauer)

建立并使用完善的工程化原則，以較經(jīng)濟的手段獲得能在實際機器上有效運行的可靠軟件的一系列方法1.2軟件工程定義(2)Softwareengineering.(1)Theapplicationofasystematic,disciplined,quantifiableapproachtothedevelopment,operation,andmaintenanceofsoftware;thatis,theapplicationofengineeringtosoftware.(2)Thestudyofapproachesasin(1).(IEEE(TheInstituteforElectricalandElectronicengineers)Std610-1993.）

軟件工程是：（1）把系統(tǒng)的、規(guī)范的、可度量的途徑應用于軟件的開發(fā)、運行和維護過程，也就是把工程應用于軟件；（2）研究（1）中提到的方法。1.2軟件工程定義總之：軟件工程是應用計算機科學、數(shù)學及管理科學等原理開發(fā)軟件的工程。它借鑒傳統(tǒng)工程的原則、方法，以提高質(zhì)量，降低成本為目的。軟件工程的本質(zhì)特性1.軟件工程關注于大型程序的構造2.軟件工程的中心課題是控制復雜性3.軟件經(jīng)常變化4.開發(fā)軟件的效率非常重要5.和諧地合作是開發(fā)軟件的關鍵6.軟件必須有效地支持它的用戶7.在軟件工程領域中是由具有一種文化背景的人替具有另一種文化背景的人創(chuàng)造產(chǎn)品1.2軟件工程定義1.2.2軟件工程的基本原理著名的軟件工程專家B.W.Boehm綜合學者們的意見并總結了TRW公司多年開發(fā)軟件的經(jīng)驗，于1983年在一篇論文中提出了軟件工程的7條基本原理。這7條原理是確保軟件產(chǎn)品質(zhì)量和開發(fā)效率的原理的最小集合。7條原理互相獨立，其中任意6條組合都不能替代另一條，同時這7條原理又是相當完備的，雖然不能用數(shù)學方法嚴格證明它們是一個完備集合。但在此之前提出的100多條軟件工程原理都可以由這7條原理任意組合蘊含或派生軟件工程的基本原理有：按軟件生存期分階段制定計劃并嚴格管理把整個軟件開發(fā)過程視為一項工程，把工程劃分為若干階段，分別制定每個階段的計劃，逐個實施。堅持進行階段評審前一階段的結果將成為下一階段的依據(jù)。堅持階段的評審才能保證錯誤不傳播到下一階段。軟件工程的基本原理堅持嚴格的產(chǎn)品控制將影響軟件質(zhì)量的因素在整個過程中置于嚴格控制之下。使用現(xiàn)代程序設計技術先進的程序設計技術帶來的是生產(chǎn)率和質(zhì)量的提高。使用合適的開發(fā)模式和工具可以有效地建立功能強大的系統(tǒng)。明確責任，使得工作結果能夠得到清楚的審查開發(fā)組織嚴格劃分責任并制定產(chǎn)品的標準，使得每個成員的工作有據(jù)可依，確保產(chǎn)品的質(zhì)量。用人少而精開發(fā)組織不在人多，在于每個人的技能適合要求。同時用人少而精，可減少溝通路徑，提高生產(chǎn)率。承認不斷改進軟件工程實踐的必要性在開發(fā)的過程中積極主動采納新的軟件技術，不斷總結經(jīng)驗，改進開發(fā)的組織和過程，有效地通過過程質(zhì)量的改進提高軟件產(chǎn)品的質(zhì)量。軟件工程包括技術和管理兩方面的內(nèi)容，是技術與管理緊密結合所形成的工程學科。通常把在軟件生命周期全過程中使用的一整套技術方法的集合稱為方法學(methodology)，也稱為范型(paradigm)。在軟件工程領域中，這兩個術語的含義基本相同。軟件工程方法學包含3個要素：方法、工具和過程。1.3軟件工程方法學1.3軟件工程方法學軟件工程：一種層次化技術質(zhì)量關注點過程方法工具

軟件工程層次圖軟件工程三個要素：工具、方法、過程基礎層，過程定義了一組關鍵過程區(qū)域框架，構成了軟件項目的管理控制的基礎，規(guī)定了技術方法的采用、工程產(chǎn)品的產(chǎn)生、成本的建立、質(zhì)量的保證及變化的適當管理。定義方法使用的順序，所需要的管理和工作步驟。為軟件開發(fā)提供“如何做”的技術方法涵蓋了一系列的任務：需求分析、設計、編程、測試和維護，方法依賴于一組基本原則，這些原則控制了每一技術區(qū)域為軟件開發(fā)提供自動或半自動的軟件支撐環(huán)境，建立計算機輔助軟件工程(CASE)的軟件開發(fā)支撐系統(tǒng)任何工程方法（包括軟件工程）必須以組織對質(zhì)量的承諾為基礎。軟件工程的根基在于質(zhì)量關注點。1.3軟件工程方法學(面向對象方法學)ALM（ApplicationLifecycleManagement）MSF（MicrosoftSolutionFramework)軟件生命周期

三個時期八個階段：軟件生命周期由軟件定義、軟件開發(fā)和運行維護(也稱為軟件維護)三個時期組成，每個時期又進一步劃分成若干個階段。三個時期：八個階段：軟件生命周期軟件定義軟件開發(fā)軟件維護問題定義可行性研究需求分析概要設計詳細設計編碼和單元測試綜合測試運行維護系統(tǒng)設計系統(tǒng)實現(xiàn)1.問題定義任務：問題是什么通過對客戶的訪問調(diào)查，系統(tǒng)分析員扼要地寫出關于問題性質(zhì)、工程目標和工程規(guī)模的書面報告。經(jīng)過討論和必要的修改之后這份報告應該得到客戶的確認。結果：關于系統(tǒng)規(guī)模和目標的報告書

2.可行性研究任務：有可行的解嗎系統(tǒng)分析員需要進行一次大大壓縮和簡化了的系統(tǒng)分析和設計過程。研究問題的范圍，探索這個問題是否值得去解，是否有可行的解決辦法。結果：系統(tǒng)的高層邏輯模型（數(shù)據(jù)流圖、成本效益分析）可行性論證報告（立即進行/推遲進行/不能或不值得進行）3.需求分析任務：必須做什么主要是確定目標系統(tǒng)必須具備哪些功能。系統(tǒng)分析員必須和用戶密切配合，充分交流信息，以得出經(jīng)過用戶確認的系統(tǒng)邏輯模型。結果：系統(tǒng)的邏輯模型（數(shù)據(jù)流圖、數(shù)據(jù)字典、簡要的算法描述）用規(guī)格說明書準確地記錄對目標系統(tǒng)的需求4.總體設計任務：如何解決已提出的問題設計出實現(xiàn)目標系統(tǒng)的幾種可能的方案（低、中、高成本）。用適當?shù)谋磉_工具描述每種方案，分析優(yōu)缺點，推薦一個最佳方案，制定出實現(xiàn)最佳方案的詳細計劃。設計程序的體系結構。結果：可能的解法推薦的系統(tǒng)體系結構（層次圖或結構圖）5.詳細設計任務：怎樣具體實現(xiàn)該系統(tǒng)詳細地設計每個模塊，確定實現(xiàn)模塊功能所需要的算法和數(shù)據(jù)結構。結果：每個模塊的算法和數(shù)據(jù)結構(程序流程圖、PAD圖、N-S圖等)。6.編碼和單元測試任務：得到正確的程序模塊選取一種適當?shù)母呒壋绦蛟O計語言(必要時用匯編語言)，把詳細設計的結果翻譯成用選定的語言書寫的程序；并且仔細測試編寫出的每一個模塊。結果：代碼和測試報告7.綜合測試任務：得到符合要求的軟件通過集成測試、驗收測試、現(xiàn)場測試、平行運行等方法對目標系統(tǒng)進一步測試檢驗。通過對軟件測試結果的分析可以預測軟件的可靠性；反之，根據(jù)對軟件可靠性的要求，也可以決定測試和調(diào)試過程什么時候可以結束。結果：測試計劃、詳細測試方案以及實際測試結果完整一致的軟件配置8.軟件維護任務：使系統(tǒng)持久地滿足用戶的需要改正性維護，診斷和改正在使用過程中發(fā)現(xiàn)的軟件錯誤；適應性維護，修改軟件以適應環(huán)境的變化；完善性維護，根據(jù)用戶的要求改進或擴充軟件；預防性維護，修改軟件為將來的維護活動做準備。每一項維護活動實質(zhì)上是經(jīng)歷了一次壓縮和簡化了的軟件定義和開發(fā)的全過程。結果：完整準確的維護記錄

各類維護工作量所占比例維護工作量在軟件生命周期所占比例1.4軟件過程模型過程定義了運用方法的順序、應該交付的文檔資料、為保證軟件質(zhì)量和協(xié)調(diào)變化所需要采取的管理措施，以及標志軟件開發(fā)各個階段任務完成的里程碑。軟件過程是為了獲得高質(zhì)量軟件所需要完成的一系列任務的框架，它規(guī)定了完成各項任務的工作步驟。軟件過程1.4軟件過程模型

軟件生命周期的每一階段都有明確的任務，把規(guī)模大、結構復雜、管理復雜的軟件開發(fā)變得容易控制和管理。各個階段的活動如何銜接，開發(fā)過程中采用什么樣的策略，應遵守什么樣的規(guī)定和制約，將這些活動框架（忽略不必要的細節(jié)）用一種模型表示出來，稱為軟件過程模型（或軟件開發(fā)模型或軟件生命周期模型）。

也就是說，

軟件過程模型是軟件開發(fā)全部過程、活動和任務的結構框架。它能直觀表達軟件開發(fā)全過程，明確規(guī)定要完成的主要活動、任務和開發(fā)策略。軟件過程模型的選擇基于項目和應用的性質(zhì)、采用的方法工具以及需要的控制和交付的產(chǎn)品。幾種典型的模型：1.4軟件過程模型（1）瀑布模型(WaterfallModel）

傳統(tǒng)瀑布模型瀑布模型也稱為線性順序模型在20世紀80年代以前，瀑布模型一直是唯一被廣泛采用的生命周期模型規(guī)定了各項活動按自上而下，相互銜接的固定次序，如同瀑布逐級下落。每項活動均處于一個質(zhì)量環(huán)（輸入-處理-輸出-評審）中。1.4軟件過程模型傳統(tǒng)瀑布模型的特點1.階段間具有順序性和依賴性。2.推遲實現(xiàn)的觀點。

清楚區(qū)分邏輯設計與物理設計，強調(diào)了每一階段活動的嚴格順序。3.質(zhì)量保證觀點：以經(jīng)過評審確認了的階段工作產(chǎn)品（文檔）驅動下一階段的工作，便于管理。每個階段必須完成規(guī)定的文檔;每個階段結束前完成文檔審查,及早改正錯誤。缺點：是一種整體開發(fā)模型，程序的物理實現(xiàn)集中在開發(fā)階段的后期，用戶在最后才能看到自己的產(chǎn)品。

傳統(tǒng)瀑布模型存在什么問題？傳統(tǒng)的瀑布模型過于理想化。事實上，人在工作過程中不可能不犯錯誤。1.4軟件過程模型實際的瀑布模型1.4軟件過程模型可強迫開發(fā)人員采用規(guī)范的方法（例如，結構化技術）；嚴格地規(guī)定了每個階段必須提交的文檔；要求每個階段交出的所有產(chǎn)品都必須經(jīng)過質(zhì)量保證小組的仔細驗證。瀑布模型的成功在很大程度上是由于它基本上是一種文檔驅動的模型。

瀑布模型適合于用戶需求明確、完整、無重大變化的軟件項目開發(fā)。瀑布模型的缺點：從認識論角度看，人的認識是一個多次反復循環(huán)的過程，不可能一次完成。但瀑布模型中劃分的幾個階段，沒有反映出這種認識過程的反復性。實際項目很少按照該模型給出的順序進行。軟件開發(fā)是一個知識密集型的開發(fā)活動，需要相互合作完成，但瀑布模型沒有體現(xiàn)這一點。用戶常常難以清楚地給出所有需求。各個階段的劃分完全固定，階段之間產(chǎn)生大量的文檔，極大地增加了工作量；由于開發(fā)模型是線性的，用戶只有等到整個過程的末期才能見到開發(fā)成果，從而增加了開發(fā)的風險；早期的錯誤可能要等到開發(fā)后期的測試階段才能發(fā)現(xiàn)，進而帶來嚴重的后果。瀑布模型的優(yōu)缺點1.4軟件過程模型（2）原型模型—快速原型模型（RapidPrototypeModel）在用戶不能給出完整、準確的需求說明，或者開發(fā)者不能確定算法的有效性、操作系統(tǒng)的適應性或人機交互的形式等許多情況下，可以根據(jù)用戶的一組基本需求，快速建造一個原型（可運行的軟件），然后進行評估，進一步精化、調(diào)整原型，使其滿足用戶的要求，也使開發(fā)者對將要做的事情有更好的理解。1.4軟件過程模型快速原型驗證規(guī)格說明驗證設計驗證編碼測試綜合測試維護變化的需求驗證維護過程開發(fā)過程快速原型模型3.原型特征軟件原型是軟件的最初版本，以最少的費用、最短的時間開發(fā)出的、可以反映最后軟件的主要特征的系統(tǒng)。它具有以下特征：它是一個可實際運行的系統(tǒng)。它沒有固定的生存期。一種極端是扔掉原型（以最簡便方式大量借用已有軟件，做出最后產(chǎn)品的模型，證實產(chǎn)品設想是成功的，但產(chǎn)品中并不使用）；另一種極端是最終產(chǎn)品的一部分即增量原型（先做出最終產(chǎn)品的核心部分，逐步增加補充模塊），演進原型居于其中（每一版本扔掉一點，增加一點，逐步完善至最終產(chǎn)品）。從需求分析到最終產(chǎn)品都可作原型，即可為不同目標作原型。它必須快速、廉價。它是迭代過程的集成部分，即每次經(jīng)用戶評價后修改、運行，不斷重復雙方認可。4.原型法的評價優(yōu)點1)原型法在得到良好的需求定義上比傳統(tǒng)生存周期法好得多，可處理模糊需求，開發(fā)者和用戶可充分通信。2)原型系統(tǒng)可作為培訓環(huán)境，有利于用戶培訓和開發(fā)同步，開發(fā)過程也是學習過程。3)原型給用戶更改心中原先設想的、不盡合理的最終系統(tǒng)的機會。4)原型可低風險開發(fā)柔性較大的計算機系統(tǒng)。5)原型增加使系統(tǒng)更易維護、對用戶更友好的機會。6)原型使總的開發(fā)費用降低，時間縮短。缺點1.“模型效應”或“管中窺豹”。對于開發(fā)者不熟悉的領域把次要部分當作主要框架，做出不切題的原型。2.原型迭代不收斂于開發(fā)者預先的目標。即每次更改，為了消除錯誤，次要部分越來越大，“淹沒”了主要部分。3.原型過快收斂于需求集合，而忽略了一些基本點。4.資源規(guī)劃和管理較為困難，隨時更新文檔也帶來麻煩。5.長期在原型環(huán)境上開發(fā)，只注意得到滿意的原型，容易“遺忘”用戶環(huán)境和原型環(huán)境的差異。1.4軟件過程模型（3）增量模型(IncrementalModel)是一種漸進地開發(fā)逐步完善的軟件版本的模型。需求分析驗證規(guī)格說明驗證概要設計驗證維護針對每個構件完成詳細設計、編碼和集成，經(jīng)測試后交付給用戶（漸增模型）

先完成一個系統(tǒng)子集的開發(fā)，再按同樣的開發(fā)步驟增加功能(系統(tǒng)子集),如此遞增下去直至滿足全部系統(tǒng)需求。系統(tǒng)的總體設計在初始子集設計階段就應作出設想。增量模型是迭代和演進的過程。增量模型把軟件產(chǎn)品分解成一系列的增量構件，在增量開發(fā)迭代中逐步加入。每個構件由多個相互作用的模塊構成，并且能夠完成特定的功能。早先完成的增量可以為后期的增量提供服務。增量開發(fā)方法的新演進版本叫做“極限程序設計（eXtremeProgramming）”。

1.4軟件過程模型分析分析分析分析設計設計設計設計編碼編碼編碼編碼測試測試測試測試增量1增量2增量3增量4交付交付交付交付●●●●●風險更大的增量模型1.4軟件過程模型在較短時間內(nèi)向用戶提交可完成部分工作的產(chǎn)品，并分批、逐步地向用戶提交產(chǎn)品。從第一個構件交付之日起，用戶就能做一些有用的工作。整個軟件產(chǎn)品被分解成許多個增量構件，開發(fā)人員可以一個構件一個構件地逐步開發(fā)。逐步增加產(chǎn)品功能可以使用戶有較充裕的時間學習和適應新產(chǎn)品，從而減少一個全新的軟件可能給客戶組織帶來的沖擊。采用增量模型比采用瀑布模型和快速原型模型需要更精心的設計，但在設計階段多付出的勞動將在維護階段獲得回報。增量模型的優(yōu)點1.4軟件過程模型增量模型的困難在把每個新的增量構件集成到現(xiàn)有軟件體系結構中時，必須不破壞原來已經(jīng)開發(fā)出的產(chǎn)品。此外，必須把軟件的體系結構設計得便于按這種方式進行擴充，向現(xiàn)有產(chǎn)品中加入新構件的過程必須簡單、方便，也就是說，軟件體系結構必須是開放的。在開發(fā)過程中，需求的變化是不可避免的。增量模型的靈活性可以使其適應這種變化的能力大大優(yōu)于瀑布模型和快速原型模型，但也很容易退化為邊做邊改模型，從而使軟件過程的控制失去整體性。開發(fā)人員既要把軟件系統(tǒng)看作整體。又要看成可獨立的構件，相互矛盾。多個構件并行開發(fā)，具有無法集成的風險。如果項目在既定的商業(yè)要求之前不可能找到足夠的開發(fā)人員，這種情況下增量模型顯得特別有用早期的增量可以由少量的人員實現(xiàn)。如果核心產(chǎn)品的口碑不錯，可為下一個增量投入更多的人力1.4軟件過程模型（4）螺旋模型(SpiralModel)軟件風險是任何軟件開發(fā)項目中都普遍存在的實際問題，項目越大，軟件越復雜，承擔該項目所冒的風險也越大。

對于復雜的大型軟件，開發(fā)一個原型往往達不到要求。螺旋模型將瀑布模型和增量模型結合起來，加入了風險分析。螺旋模型是一種迭代模型，它把開發(fā)過程分為幾個螺旋周期，每迭代一次，螺旋線就前進一周。在該模型中，軟件開發(fā)是一系列的增量發(fā)布，早期的迭代中，發(fā)布的增量可能是一個紙上的模型或原型，在以后的迭代中，逐步產(chǎn)生系統(tǒng)更加完善的版本。螺旋模型的基本思想是降低風險。軟件風險產(chǎn)品交付給用戶后用戶可能不滿意；到了預定的交付日期軟件可能還未開發(fā)出來；實際的開發(fā)成本可能超過預算；產(chǎn)品完成前一些關鍵的開發(fā)人員“跳槽”了；產(chǎn)品投入市場之前競爭對手發(fā)布了一個功能相近、價格更低的軟件等。任何軟件開發(fā)都有風險1.4軟件過程模型快速原型驗證規(guī)格說明驗證設計驗證編碼測試綜合測試維護變化的需求驗證風險分析風險分析風險分析風險分析風險分析風險分析可看作在每個階段之前都增加了風險分析過程的快速原型模型。簡化的螺旋模型在原型基礎上，進行多次原型反復并增加風險評估，形成螺旋模型。1.4軟件過程模型完整的螺旋模型制定計劃風險分析實施工程客戶評估1.4軟件過程模型螺旋模型的優(yōu)點對可選方案和約束條件的強調(diào)有利于已有軟件的重用，也有助于把軟件質(zhì)量作為軟件開發(fā)的一個重要目標減少了過多測試或測試不足維護和開發(fā)之間并沒有本質(zhì)區(qū)別螺旋模型的缺點風險驅動，需要相當豐富的風險評估經(jīng)驗和專門知識，否則風險更大主要適用于內(nèi)部開發(fā)的大規(guī)模軟件項目，隨著過程的進展演化，開發(fā)者和用戶能夠更好的識別和對待每一個演化級別上的風險隨著迭代次數(shù)的增加，工作量加大，軟件開發(fā)成本增加1.4軟件過程模型（5）面向對象模型噴泉模型(FountainModel)噴泉模型認為軟件生命周期的各個階段是相互重疊和多次反復的。特點：體現(xiàn)了迭代和無間隙的特性。在一個階段內(nèi)的向下箭頭代表該階段內(nèi)的迭代（或求精）。無間隙是指在各項開發(fā)活動，即分析、設計和編碼之間不存在明顯的邊界。圓圈相互重疊表示兩個活動之間存在交疊。系統(tǒng)某個部分常常重復工作多次，相關對象在每次迭代中隨之加入演進的軟件成分。代表維護的圓圈較小象征著采用了面向對象范型后維護時間縮短了。噴泉模型是對象驅動的過程。1.4軟件過程模型可重用部件組裝模型(構件集成模型)

(ComponentIntegrationModel)構件（components)也稱為組件，是一段有確定接口的程序體，具有自己的功能和邏輯，能同其他構件集成起來協(xié)調(diào)工作。該模型支持軟件重用（Reusability）

，對縮短軟件開發(fā)周期、降低項目成本有重要的現(xiàn)實意義。同時，建造符合某應用領域體系結構標準的構件，可以用來搭建分布式的、跨越不同操作平臺(集成化軟件開發(fā)環(huán)境（ISDE）)的軟件，擴展了軟件的應用前景，促進了軟件標準化、商品化的發(fā)展。因此，在此基礎上專家們又提出了“基于構件的軟件工程”(CBSE)。構件集成模型如下圖所示：1.4軟件過程模型

構件集成模型軟件體系結構被建立后，必須用構件去充實，這些構件可從復用庫中獲得，或者根據(jù)專門需要而開發(fā)。整個過程可以演化地進行，面向對象方法給予技術上的支持。1.4軟件過程模型

構件技術主要有三種流行標準：OMG的CORBA(公共對象請求代理體系結構)微軟的構件對象模型COM/DCOM(組件對象模型)SUN的EJB(EnterpriseJavaBean)--JavaEE服務器端組件模型1.4軟件過程模型（6）統(tǒng)一軟件開發(fā)過程

是由Rational公司的Booch、Jacobson、Rumbaugh提出的軟件過程模型，也稱RUP（RationalUnifiedProcess)。RUP重復一系列周期，每個周期由一個交付給用戶的產(chǎn)品結束。每個周期劃分為初始、細化、構造和移交四