軟件工程導論

鄧娜計算機學院

1/70課程介紹及要求用工程化的方法來開發(fā)軟件2/84教學目標為什么要學習這門課程有助于正確理解和認識“軟件”的概念及其特點理解軟件開發(fā)面臨的問題和挑戰(zhàn)掌握軟件工程的原則、方法和思想來系統(tǒng)地開發(fā)軟件，尤其是復雜、龐大的軟件的開發(fā)了解和接觸軟件開發(fā)所需的各種技術(shù)手段理解、掌握和運用3/84理解什么是軟件工程為什么需要軟件工程(產(chǎn)生背景)軟件工程需要解決那些問題軟件工程涉及那些方面內(nèi)容4/84掌握軟件工程概念技術(shù)過程手段工具5/84運用運用工程化思想進行軟件開發(fā)需求分析軟件設計程序設計軟件維護6/84先導要求程序設計語言最好有一定的軟件開發(fā)經(jīng)驗7/84學習要求聽理解知識點和思想無需死記硬背做實踐體會軟件工程的原則、方法和技術(shù)，在實踐中提高培養(yǎng)抽象思維能力培養(yǎng)獨立解決問題的能力培養(yǎng)合作精神想閱讀相關(guān)資料8/84考核方式考試(60%)課程設計(30%)考勤(10%)9/84課程設計(1/2)內(nèi)容選擇一個項目開發(fā)課題，用軟件工程的思想知道其開發(fā)過程。完成需求分析，詳細設計，測試，項目匯報。分組以小組為單位，6—8人一組為宜時間平時可以分組著手準備和進行，期末考試前要交，具體時間待定10/84課程實習要求(2/2)提交內(nèi)容課程設計紙質(zhì)文檔，裝入文件袋評價方法文檔:完整性、合理性、規(guī)范性11/84教材和課件教材薛繼偉高等學?！笆濉币?guī)劃教材?計算機軟件工程系列:軟件工程導論，第1版哈爾濱工業(yè)大學出版社課件下載公共郵箱（還未申請）12/84參考文獻軟件工程導論（第五版），張海藩，清華大學出版社軟件工程實踐導論--有關(guān)方法、設計、實現(xiàn)、管理之三十六計，金尊和，清華大學出版社，2005.軟件開發(fā)的科學與藝術(shù)，微軟亞洲研究院，電子工業(yè)出版社，2002

年

軟件工程－實踐者的研究方法，RS.Pressman,機械工業(yè)出版社現(xiàn)代軟件工程,周之英編著,科學出版社13/84參考書籍14/84第1章軟件工程概述軟件工程產(chǎn)生的背景(軟件危機)軟件工程定義軟件工程方法學軟件過程模型軟件工程知識體系軟件工程師道德規(guī)范小結(jié)15/841.1軟件工程產(chǎn)生的背景軟件

a.軟件的定義軟件（

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

，數(shù)據(jù)（Data）及其相關(guān)文檔（Document）的完整集合。Software=Program+Data+Document程序是按事先設計的功能和性能要求執(zhí)行的指令序列數(shù)據(jù)是使程序能正常操縱信息的數(shù)據(jù)結(jié)構(gòu)文檔是與程序開發(fā)，維護和使用有關(guān)的圖文材料16/84非常復雜邏輯復雜遠遠高于硬件的邏輯復雜度開發(fā)復雜成本難以估算進度難以控制人員素質(zhì)要求質(zhì)量得不到保證1.1軟件工程產(chǎn)生的背景

b、軟件的特征17/84成本高1.1軟件工程產(chǎn)生的背景

b、軟件的特征18/84風險大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)生的背景

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

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

軟件危機1963年美國飛往火星的火箭爆炸，造成1000萬美元的損失。原因是FORTRAN程序：

DO5Ⅰ=1，3

誤寫成：DO5Ⅰ=1.31967年蘇聯(lián)“聯(lián)盟一號”載人宇宙飛船在返航時，由于軟件忽略一個小數(shù)點，在進入大氣層時因打不開降落傘而燒毀。22/84美國IBM公司在1963年至1966年開發(fā)的IBM360機的操作系統(tǒng)。5000人-年的工作量，1000人投入，近100萬行源程序。每次發(fā)行的新版本都是從前一版本中找1000個程序錯誤，項目負責人F.D.Brook總結(jié)時說：“正像一只逃亡的野獸落到泥潭中做垂死的掙扎，越是掙扎，陷得越深。最后無法逃脫滅頂?shù)臑碾y?！?/p>

軟件危機23/841.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億美元計算機軟件和硬件費用比24/84軟件質(zhì)量得不到保證軟件應用面的擴大：科學計算、軍事、航空航天、工業(yè)控制、企業(yè)管理、辦公、家庭軟件越來越多的應用于安全攸關(guān)(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）25/84a、軟件危機的表現(xiàn)（3/3）進度難以控制項目延期比比皆是由于進度問題而取消的軟件項目較常見只有一小部分的項目能夠按期完成維護非常困難軟件維護的多樣性軟件維護的復雜性軟件維護的副作用26/84軟件危機主要有以下表現(xiàn)：對軟件開發(fā)成本和進度的估計常常不準確。開發(fā)成本超出預算，實際進度比預定計劃一再拖延的現(xiàn)象并不罕見。用戶對“已完成”系統(tǒng)不滿意的現(xiàn)象經(jīng)常發(fā)生。軟件產(chǎn)品的質(zhì)量往往靠不住。Bug一大堆，Patch一個接一個。軟件的可維護程度非常之低。軟件通常沒有適當?shù)奈臋n資料。軟件的成本不斷提高。軟件開發(fā)生產(chǎn)率的提高趕不上硬件的發(fā)展和人們需求的增長。27/84b、產(chǎn)生軟件危機的原因與軟件本身的特點有關(guān)(難于維護,邏輯復雜)與軟件開發(fā)與維護的方法不正確有關(guān):軟件≠程序急于求成=拔苗助長各自為陣無方法/學28/84引入同一變化付出的代價隨時間變化的趨勢29/84消除軟件危機的途徑對計算機軟件有一個正確的認識

(軟件≠程序）必須充分認識到軟件開發(fā)不是某種個體勞動的神秘技巧，而應該是一種組織良好、管理嚴密、各類人員協(xié)同配合、共同完成的工程項目。非個人英雄主義推廣使用在實踐中總結(jié)出來的開發(fā)軟件的成功技術(shù)和方法。開發(fā)和使用更好的軟件工具。30/84開發(fā)一個具有一定規(guī)模和復雜性的軟件系統(tǒng)與編寫一個簡單的程序不一樣正如建設狗窩和高樓大廈大型、復雜軟件系統(tǒng)的開發(fā)是一項工程，必須按照工程化的方法組織軟件的生產(chǎn)和管理，必須經(jīng)過分析、設計、實現(xiàn)、測試、維護等一系列軟件過程和活動C、軟件工程（學）因危機而產(chǎn)生31/84軟件工程工程工程是對技術(shù)（或社會）實體的分析、設計、建造、驗證和管理?！こ探ㄖこ虣C械工程軟件工程傳統(tǒng)工程新興工程氣象工程生物工程32/84軟件工程----SoftwareEngineering于1968年NATO組織在德國召開的一次會議上提出是把軟件當作一種工業(yè)產(chǎn)品，要求“采用工程化的原理與方法對軟件進行計劃、開發(fā)和維護”。33/84圍棋與軟件工程的感想圍棋圍棋棋譜拿過來的時候,大師問“后面應該走哪里？”十個初級愛好者選擇的落點散布在棋盤各處……

十個職業(yè)棋手說的落子點都差不多，甚至包括后面的幾步……

這就是高手和低手的差別……軟件工程當一個小程序拿過來的時候,項目經(jīng)理讓大家編寫……

十個中國軟件工程師寫出來的程序各有“特色”、千差萬別，十個印度軟件工程師寫出來的程序差不多，以至于懷疑是“抄襲”。項目經(jīng)理也不清楚中國軟件業(yè)和印度軟件業(yè)的差距是多少年只是覺得差了好遠好遠……34/84d、軟件工程(學):克服軟件危機的努力

（1）從管理的角度

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

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

結(jié)構(gòu)化軟件開發(fā)方法,面向?qū)ο蟮拈_發(fā)35/84提出有效的方法和工具支持軟件開發(fā)1968年提出軟件工程概念和思想20世紀70年代的結(jié)構(gòu)化軟件開發(fā)方法20世紀80年代的面向?qū)ο蟮能浖_發(fā)方法新的技術(shù):軟件重用、快速原型、需求工程典型技術(shù):COM,Java,C++,J2EE,.Net,….支撐工具和環(huán)境：Jbuilder,VisualStudio,WebLogic,…1、解決危機的技術(shù)途徑36/8420世紀80年代末，美國國防部DoD和工業(yè)界開始認識到管理的重要性美國DoD的一項研究表明，70%的項目由于管理不善導致難以控制進步、成本和質(zhì)量；進一步的研究發(fā)現(xiàn)：管理是影響軟件項目成功開發(fā)的全局性因素，而技術(shù)只影響局部如果軟件開發(fā)組織不能對軟件項目進行有效管理，就不能充分發(fā)揮軟件開發(fā)方法和工具的潛力，也就不能高效率地開發(fā)出高質(zhì)量的軟件產(chǎn)品2、解決危機的管理途徑37/841.2軟件工程定義(1)Theestablishmentanduseofsoundengineeringprinciples(methods)inordertoobtaineconomicallysoftwarethatisreliableandworksonrealmachines.(1968-FritzBauer)

軟件工程就是建立和使用一套合理的工程原理，從而經(jīng)濟地獲得可靠的、可以在實際機器上高效運行的軟件。38/841.2軟件工程定義(2)Softwareengineering.(1)Theapplicationofasystematic,disciplined,quantifiableapproachtothedevelopment,operation,andmaintenanceofsoftware;thatis,theapplicationofengineeringtosoftware.(2)Thestudyofapproachesasin(1).(IEEE(TheInstituteforElectricalandElectronicengineers)Std610-1990.）

軟件工程是：（1）把系統(tǒng)的、規(guī)范的、可度量的途徑應用于軟件開發(fā)、運行和維護過程，也就是把工程應用于軟件；（2）研究（1）中提到的途徑。39/841.2軟件工程定義(3)

Engineeringisthe

systematicapplicationofscientificknowledge

increatingandbuildingcost-effectivesolutionstopracticalproblemsintheserviceofmankind.

Softwareengineeringisthat

formofengineering

thatappliestheprinciplesofcomputerscienceandmathematics

toachievingcost-effectivesolutionstosoftwareproblems.SEIsoftwareengineeringdefinitionfrom1990SEIReportonUndergraduateSoftwareEngineeringEducation(卡耐基梅隆大學在本科生軟件工程教育的報告):40/841.2軟件工程定義總之：軟件工程是應用計算機科學、數(shù)學及管理科學等原理開發(fā)軟件的工程。它借鑒傳統(tǒng)工程的原則、方法，以提高質(zhì)量，降低成本為目的。41/84軟件工程是一門交叉學科軟件工程的主要研究內(nèi)容軟件開發(fā)技術(shù):軟件開發(fā)方法學軟件開發(fā)過程軟件工具和軟件工程環(huán)境軟件工程管理:軟件管理學軟件經(jīng)濟學軟件心理學42/84軟件工程與一般工程的差異軟件是邏輯產(chǎn)品而不是實物產(chǎn)品軟件的功能依賴于硬件和軟件的運行環(huán)境以及人們對它的操作軟件設計的復雜性軟件特征：功能的多樣性實現(xiàn)的多樣性能見度低軟件結(jié)構(gòu)合理性差智力密集及知識產(chǎn)權(quán)保護43/84軟件工程包括技術(shù)和管理兩方面的內(nèi)容，是技術(shù)與管理緊密結(jié)合所形成的工程學科。通常把在軟件生命周期全過程中使用的一整套技術(shù)方法的集合稱為方法學(methodology)，也稱為范型(paradigm)。在軟件工程領域中，這兩個術(shù)語的含義基本相同。軟件工程方法學包含3個要素：方法、工具和過程。1.3軟件工程方法學44/841.3軟件工程方法學軟件工程：一種層次化技術(shù)質(zhì)量關(guān)注點過程方法工具

軟件工程層次圖軟件工程三個要素：工具、方法、過程基礎層，綜合方法及工具，定義方法使用的順序，所需要的管理為軟件開發(fā)提供“如何做”的技術(shù)為軟件開發(fā)提供自動或半自動的軟件支撐環(huán)境，建立計算機輔助軟件工程(CASE)的軟件開發(fā)支撐系統(tǒng)45/841.4軟件生命周期模型問題定義軟件定義可行性研究

需求分析

總體設計詳細設計軟件生命周期軟件開發(fā)編碼單元測試綜合測試運行維護

持久滿足用戶需求46/841.4軟件過程模型軟件過程是為了獲得高質(zhì)量軟件所需要完成的一系列任務的框架，它規(guī)定了完成各項任務的工作步驟。AprocessdefinesWhoisdoingWhat,When,andHow,inordertoreachacertaingoal.公共過程框架輔助活動任務集合軟件過程47/841.4軟件過程模型

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

也就是說，

軟件過程模型是軟件開發(fā)全部過程、活動和任務的結(jié)構(gòu)框架。48/841.4軟件過程模型（1）瀑布模型(WaterfallModel）

傳統(tǒng)瀑布模型瀑布模型也稱為線性順序模型,在20世紀80年代以前，瀑布模型一直是唯一被廣泛采用的生命周期模型49/841.4軟件過程模型傳統(tǒng)瀑布模型的特點提供了軟件過程模型的基本框架（模板）。強調(diào)了每一階段活動的嚴格順序。質(zhì)量保證觀點：以經(jīng)過評審確認了的階段工作產(chǎn)品（文檔）驅(qū)動下一階段的工作，便于管理。是一種整體開發(fā)模型，程序的物理實現(xiàn)集中在開發(fā)階段的后期，用戶在最后才能看到自己的產(chǎn)品。

傳統(tǒng)瀑布模型存在什么問題？50/841.階段間具有順序性和依賴性。2.推遲實現(xiàn)的觀點。3.傳統(tǒng)的瀑布模型過于理想化。事實上，人在工作過程中不可能不犯錯誤。在設計階段可能發(fā)生規(guī)格說明文檔中的錯誤。而設計上的缺陷或錯誤可能在實現(xiàn)過程中顯現(xiàn)出來。在綜合測試階段將發(fā)現(xiàn)需求分析、設計或編碼階段的許多錯誤傳統(tǒng)化（理想化）瀑布模型的缺點51/841.4軟件過程模型實際的瀑布模型52/841.4軟件過程模型瀑布模型適合于用戶需求明確、完整、無重大變化的軟件項目開發(fā)。瀑布模型的成功在很大程度上是由于它基本上是一種文檔驅(qū)動的模型?？蓮娖乳_發(fā)人員采用規(guī)范的方法嚴格地規(guī)定了每個階段必須提交的文檔；要求每個階段交出的所有產(chǎn)品都必須經(jīng)過質(zhì)量保證小組的仔細驗證“瀑布模型是由文檔驅(qū)動的”這個事實也是它的一個主要缺點。實際項目很少按照該模型給出的順序進行；用戶常常難以清楚地給出所有需求；用戶必須有耐心，等到系統(tǒng)開發(fā)完成。

瀑布模型的優(yōu)缺點53/841.4軟件過程模型（2）原型模型—快速原型模型（RapidPrototypeModel）在用戶不能給出完整、準確的需求說明，或者開發(fā)者不能確定算法的有效性、操作系統(tǒng)的適應性或人機交互的形式等許多情況下，可以根據(jù)用戶的一組基本需求，快速建造一個原型（可運行的軟件），然后進行評估，進一步精化、調(diào)整原型，使其滿足用戶的要求，也使開發(fā)者對將要做的事情有更好的理解。建造/修改原型

聽取用戶意見用戶測試運行原型原型實現(xiàn)范型54/841.4軟件過程模型快速原型驗證規(guī)格說明驗證設計驗證編碼測試綜合測試維護變化的需求驗證維護過程開發(fā)過程55/841.4軟件過程模型原型模型存在的問題

⑴為了使原型盡快的工作，沒有考慮軟件的總體質(zhì)量和長期的可維護性。

⑵為了演示，可能采用不合適的操作系統(tǒng)、編程語言、效率低的算法，這些不理想的選擇成了系統(tǒng)的組成部分。

⑶開發(fā)過程不便于管理。有效的使用原型模式建造原型僅是為了定義需求，之后就被拋棄（或被部分拋棄），實際的軟件在充分考慮了質(zhì)量和可維護性之后才被開發(fā)。56/841.4軟件過程模型（3）增量模型(IncrementalModel)是一種漸進地開發(fā)逐步完善的軟件版本的模型。需求分析驗證規(guī)格說明驗證設計驗證維護針對每個構(gòu)件完成詳細設計、編碼和集成，經(jīng)測試后交付給用戶57/841.4軟件過程模型分析分析分析分析設計設計設計設計編碼編碼編碼編碼測試測試測試測試增量1增量2增量3增量4交付交付交付交付●●●●●

?

反復的應用瀑布模型的基本成分和原型模型的迭代特征，每一個線型過程產(chǎn)生一個“增量”的發(fā)布或提交，該增量均是一個可運行的產(chǎn)品。

?

早期的版本實現(xiàn)用戶的基本需求，并提供給用戶評估的平臺。增量模型58/841.4軟件過程模型在較短時間內(nèi)向用戶提交可完成部分工作的產(chǎn)品，并分批、逐步地向用戶提交產(chǎn)品。從第一個構(gòu)件交付之日起，用戶就能做一些有用的工作。整個軟件產(chǎn)品被分解成許多個增量構(gòu)件，開發(fā)人員可以一個構(gòu)件一個構(gòu)件地逐步開發(fā)。逐步增加產(chǎn)品功能可以使用戶有較充裕的時間學習和適應新產(chǎn)品，從而減少一個全新的軟件可能給客戶組織帶來的沖擊。采用增量模型比采用瀑布模型和快速原型模型需要更精心的設計，但在設計階段多付出的勞動將在維護階段獲得回報。增量模型的優(yōu)點59/841.4軟件過程模型增量模型的困難在把每個新的增量構(gòu)件集成到現(xiàn)有軟件體系結(jié)構(gòu)中時，必須不破壞原來已經(jīng)開發(fā)出的產(chǎn)品。此外，必須把軟件的體系結(jié)構(gòu)設計得便于按這種方式進行擴充，向現(xiàn)有產(chǎn)品中加入新構(gòu)件的過程必須簡單、方便，也就是說，軟件體系結(jié)構(gòu)必須是開放的。開發(fā)人員既要把軟件系統(tǒng)看作整體。又要看成可獨立的構(gòu)件，相互矛盾。多個構(gòu)件并行開發(fā)，具有無法集成的風險。60/84增量模型適用的情況客戶能夠接受分階段交付工期緊且可分階段提交或者對目標、環(huán)境不熟悉用戶可參與到整個軟件開發(fā)過程中軟件開發(fā)組織自己應該擁有較好的類庫、構(gòu)件庫軟件企業(yè)開發(fā)大型項目時，一般還是采用增量模型，因為可以根據(jù)輕重緩急，逐個實現(xiàn)子系統(tǒng)61/84增量模型與瀑布模型、快速原型模型區(qū)別：瀑布模型、快速原型模型：一次性地把一個滿足所有需求的產(chǎn)品交付給用戶增量模型：分批交付VS62/841.4軟件過程模型（4）螺旋模型(SpiralModel)

軟件風險是任何軟件開發(fā)項目中都普遍存在的實際問題，項目越大，軟件越復雜，承擔該項目所冒的風險也越大。——產(chǎn)品交付給用戶后用戶可能不滿意；——到了預定的交付日期軟件可能還未開發(fā)出來；——實際的開發(fā)成本可能超過預算；——產(chǎn)品完成前一些關(guān)鍵的開發(fā)人員“跳槽”了；——產(chǎn)品投入市場之前競爭對手發(fā)布了一個功能相近、價格更低的軟件等。63/841.4軟件過程模型（4）螺旋模型(SpiralModel)

對于復雜的大型軟件，開發(fā)一個原型往往達不到要求。螺旋模型將瀑布模型和增量模型結(jié)合起來，加入了風險分析。在該模型中，軟件開發(fā)是一系列的增量發(fā)布，早期的迭代中，發(fā)布的增量可能是一個紙上的模型或原型，在以后的迭代中，逐步產(chǎn)生系統(tǒng)更加完善的版本。螺旋模型的基本思想是降低風險。64/841.4軟件過程模型快速原型驗證規(guī)格說明驗證設計驗證編碼測試綜合測試維護變化的需求驗證風險分析風險分析風險分析風險分析風險分析風險分析可看作在每個階段之前都增加了風險分析過程的快速原型模型。簡化的螺旋模型65/84

66/84每一次迭代都包含以下步驟：

1.決定目標、替代方案和約束2.識別和解決項目的風險3.評估技術(shù)方案和替代解決方案4.開發(fā)本次迭代的交付物和驗證迭代產(chǎn)出的正確性5.計劃下一次迭代6.提交下一次迭代的步驟和方案67/841.4軟件過程模型螺旋模型的優(yōu)點對可選方案和約束條件的強調(diào)有利于已有軟件的重用，也有助于把軟件質(zhì)量作為軟件開發(fā)的一個重要目標；減少了過多測試（浪費資金）或測試不足（產(chǎn)品故障多）所帶來的風險；更重要的是，在螺旋模型中維護只是模型的另一個周期，在維護和開發(fā)之間并沒有本質(zhì)區(qū)別68/84螺旋模型的缺點風險驅(qū)動，需要相當豐富的風險評估經(jīng)驗和專門知識，否則風險更大要求用戶參與階段評估過多的迭代次數(shù)增加了開發(fā)成本，延遲了提交時間69/84螺旋模型適用的情況內(nèi)部開發(fā)的大規(guī)模軟件項目：方便中止但是如果風險分析費用接近整個項目的預算，則風險分析是不可行的不確定因素很多，很多東西開始無法計劃的情況70/841.4軟件過程模型（5）噴泉模型(FountainModel)特點：主要用于支持面向?qū)ο箝_發(fā)過程，體現(xiàn)了面向?qū)ο蠓椒ㄋ逃械牡蜔o間隙的特征71/84認為軟件開發(fā)過程自下而上周期的各階段是相互迭代和無間隙的特性。軟件的某個部分常常被重復工作多次，相關(guān)對象在每次迭代中隨之加入漸進的軟件成分。無間隙指在各項活動之間無明顯邊界，如分析和設計活動之間沒有明顯的界限

72/84噴泉模型的特點規(guī)定了五個階段：分析、設計、實現(xiàn)、維護和演化高層到底層無資源消耗資源消耗呈塔狀，在分析階段消耗最多資源各階段的重疊反映了軟件過程的并行性增量開發(fā)，是迭代的逐步提煉的過程73/84四種模型的總結(jié)：瀑布模型歷史悠久、廣為人知，它的優(yōu)勢在于它是規(guī)范的、文檔驅(qū)動的方法；這種模型的問題是，最終開發(fā)出的軟件產(chǎn)品可能并不是用戶真正需要的?？焖僭湍Ｐ驼菫榱丝朔俨寄Ｐ偷娜秉c而提出來的。它通過快速構(gòu)建起一個可在計算機上運行的原型系統(tǒng)，讓用戶試用原型并收集用戶反饋意見的辦法，獲取用戶的真實需求。增量模型具有可在軟件開發(fā)的早期階段使投資獲得明顯回報和較易維護的優(yōu)點，但是，要求軟件具有開放的結(jié)構(gòu)是使用這種模型時固有的困難。風險驅(qū)動的螺旋模型適用于內(nèi)部開發(fā)的大型軟件項目，但是，只有在開發(fā)人員具有風險分析和排除風險的經(jīng)驗及專門知識時，使用這種模型才會獲得成功。741.4軟件過程模型（6）可重用部件組裝模型(構(gòu)件集成模型)

(ComponentIntegrationModel)

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

，對縮短軟件開發(fā)周期、降低項目成本有重要的現(xiàn)實意義。構(gòu)件集成模型如下圖所示：75/84

構(gòu)件集成模型軟件體系結(jié)構(gòu)被建立后，必須用構(gòu)件去充實，這些構(gòu)件可從復用庫中獲得，或者根據(jù)專門需要而開發(fā)。76/84軟件工程知識體系指南（2004版）

GuidetotheSoftwareEngineeringBodyofKnowledge2004Version