軟件工程概述學(xué)習(xí)課件

1、1第1章 軟件工程概念2 1.1 軟件的概念、特點(diǎn)和分類3軟件的概念軟件是計(jì)算機(jī)系統(tǒng)中與硬件相互依存的另一部分,它包括程序 、數(shù)據(jù)、相關(guān)文檔的完整集合以及完善的售后服務(wù)。 軟件=程序+數(shù)據(jù)+文檔+服務(wù)軟件與硬件、數(shù)據(jù)庫、人、過程等共同構(gòu)成計(jì)算機(jī)系統(tǒng)。4軟件的特點(diǎn)1.軟件是一種邏輯實(shí)體，而不是具體的物理實(shí)體。2.軟件的生產(chǎn)于硬件不同。3.在軟件的運(yùn)行和使用期間，沒有硬件那樣的機(jī)械磨損，老化問題。失效率時(shí)間磨合 調(diào)整 磨損用壞硬件失效曲線失效率時(shí)間軟件失效曲線理想曲線實(shí)際曲線5軟件的特點(diǎn)4.軟件的開發(fā)和運(yùn)行常常受到計(jì)算機(jī)系統(tǒng)的限制，對(duì)計(jì)算機(jī)系統(tǒng)有著不同程度的依賴。5.軟件的開發(fā)至今尚未完全擺脫手工

2、業(yè)的開發(fā)方法。6.軟件是復(fù)雜的，人類能夠創(chuàng)造的最復(fù)雜的產(chǎn)物是計(jì)算機(jī)軟件。7.軟件成本相當(dāng)昂貴。8.相當(dāng)多的軟件工作涉及到社會(huì)因素。6軟件的分類1.按軟件的功能劃分 系統(tǒng)軟件操作系統(tǒng)數(shù)據(jù)庫管理系統(tǒng)設(shè)備驅(qū)動(dòng)程序通信處理程序等7軟件的分類 支撐軟件文本編輯程序文件格式化程序磁盤向磁帶向數(shù)據(jù)傳輸?shù)某绦虺绦驇煜到y(tǒng)支持需求分析、設(shè)計(jì)、實(shí)現(xiàn)、測試和支持管理的軟件8軟件的分類 應(yīng)用軟件商業(yè)數(shù)據(jù)處理軟件工程與科學(xué)計(jì)算軟件計(jì)算機(jī)輔助設(shè)計(jì)制造軟件系統(tǒng)仿真軟件智能產(chǎn)品嵌入軟件醫(yī)療、制藥軟件事務(wù)管理、辦公自動(dòng)化軟件計(jì)算機(jī)輔助教學(xué)軟件9軟件的分類2.按軟件規(guī)模劃分類別 參加人員數(shù) 研制期限 源程序行數(shù) 微型 1 14周

3、0.5k 小型 1 16月 1k2k中型 25 12年 5k50k大型 520 23年 50k100k甚大型 1001000 45年 1M(=1000k)極大型 20005000 510年 1M10M10軟件的分類3.按軟件工作方式劃分 實(shí)時(shí)處理軟件 交互式軟件 分時(shí)軟件 批處理軟件4.按軟件服務(wù)對(duì)象的范圍劃分 項(xiàng)目軟件 產(chǎn)品軟件11軟件的分類5.按軟件使用的頻度劃分僅供一次使用的軟件 頻繁使用的軟件6.按軟件的失效 高可靠性軟件。 一般可靠性軟件。12軟件的發(fā)展軟件的發(fā)展大體經(jīng)歷了如下三個(gè)階段： 程序設(shè)計(jì)階段，約為50至60年代 特點(diǎn)：依賴于個(gè)人編程技巧 ，開發(fā)不規(guī)范，開發(fā)成本難控制，其交付

4、的產(chǎn)品主要是程序。 程序系統(tǒng)階段，約為60至70年代 特點(diǎn)：軟件開發(fā)是以小組的形式出現(xiàn)，提交的軟件產(chǎn)品除了程序外還有相應(yīng)的使用說明書。 軟件的發(fā)展遇到了很多急需解決的問題。 軟件工程階段，約為70年代以后 特點(diǎn)：開發(fā)方法遵循工程化的方法，按照軟件生命周期分階段開發(fā)軟件，提交的軟件產(chǎn)品除了程序之外，還有嚴(yán)格的文檔。13什么是軟件危機(jī)定義：軟件危機(jī)是計(jì)算機(jī)軟件在它的開發(fā)和維護(hù)過程中所遇到的一系列嚴(yán)重問題。 主要包含兩方面的問題： 如何開發(fā)軟件，怎樣滿足對(duì)軟件日益增長的需求； 如何維護(hù)數(shù)量不斷膨脹的已有軟件。14軟件危機(jī)的現(xiàn)象 對(duì)軟件開發(fā)成本和進(jìn)度的估計(jì)常常很不準(zhǔn)確。 用戶對(duì)“已完成的”軟件系統(tǒng)不滿

5、意的現(xiàn)象經(jīng)常發(fā)生。 軟件產(chǎn)品的質(zhì)量往往靠不住。 軟件常常是不可維護(hù)的。 軟件通常沒有適當(dāng)?shù)奈臋n資料。計(jì)算機(jī)軟件不僅僅是程序，還應(yīng)該有一整套文檔資料。 軟件成本在計(jì)算機(jī)系統(tǒng)總成本中所占的比例逐年上升。 軟件開發(fā)生產(chǎn)率提高的速度，遠(yuǎn)遠(yuǎn)跟不上計(jì)算機(jī)應(yīng)用迅速普及深入的趨勢。15軟件危機(jī)的原因客觀：軟件本身特點(diǎn)軟件的規(guī)模龐大、復(fù)雜性高。主觀：不正確的開發(fā)方法，軟件開發(fā)和維護(hù)有許多錯(cuò)誤的認(rèn)識(shí)和作法。忽視需求分析軟件開發(fā)=程序編寫輕視軟件維護(hù)16軟件的神話管理者的神話負(fù)責(zé)軟件的管理者像大多數(shù)其他管理者一樣，都有巨大的壓力，要維持預(yù)算，保持進(jìn)度和提高質(zhì)量。神話：我們已經(jīng)有了關(guān)于建造軟件的標(biāo)準(zhǔn)和規(guī)程的書籍，難道

6、它們不能給人們提供所有其需要知道的信息嗎？事實(shí)：不錯(cuò)，關(guān)于標(biāo)準(zhǔn)的書籍已經(jīng)存在，但真正用到了它們嗎？軟件實(shí)踐者知道它們存在嗎？它們是否反映了現(xiàn)代軟件開發(fā)的過程？它們完整嗎？很多情況下對(duì)于這些問題的答案是“否”。17軟件的神話管理者的神話神話：我們已經(jīng)有了很多很好的軟件開發(fā)工具，而且，我們?yōu)樗鼈冑I了最新的計(jì)算機(jī)。事實(shí)：為了使用最新型號(hào)的計(jì)算機(jī)、工作站和PC機(jī)去開發(fā)高質(zhì)量的軟件，我們已經(jīng)投入了太多的費(fèi)用。實(shí)際上，計(jì)算機(jī)輔助軟件工程（CASE）工具比起硬件而言，對(duì)于獲得高質(zhì)量和高生產(chǎn)率更為重要，但大多數(shù)軟件開發(fā)者并未使用它們。18軟件的神話管理者的神話神話：如果我們已落后于計(jì)劃，可以增加更多的程序員來

7、趕上進(jìn)度。事實(shí)：軟件開發(fā)并非像制造一樣是一個(gè)機(jī)械過程。用Brooks的話來說，“給一個(gè)已經(jīng)延遲的軟件項(xiàng)目增加人手只會(huì)使其更加延遲”?？雌饋?，這句話與人的直覺正好相反。但實(shí)際上，增加新人，原來正在工作的開發(fā)者必須花時(shí)間來培訓(xùn)新人，這樣就減少了他們花在項(xiàng)目開發(fā)上的時(shí)間。人手可以增加，但只能在計(jì)劃周密、協(xié)調(diào)良好的情況下。19軟件的神話用戶的神話需要計(jì)算機(jī)軟件的用戶可能就是鄰桌，或是另一個(gè)技術(shù)組，也可能是市場銷售部門，或另一個(gè)公司。在許多情況下，用戶相信關(guān)于軟件的神話，因?yàn)樨?fù)責(zé)軟件的管理者和開發(fā)者很少去糾正用戶的錯(cuò)誤理解。神話導(dǎo)致了用戶過高的期望值，并引起對(duì)開發(fā)者的極端不滿。神話：有了對(duì)目標(biāo)的一般描述

8、就足以開始寫程序了我們可以以后補(bǔ)充細(xì)節(jié)。事實(shí)：不完善的系統(tǒng)定義是軟件項(xiàng)目失敗的主要原因。關(guān)于待開發(fā)項(xiàng)目的應(yīng)用領(lǐng)域、功能、性能、接口、設(shè)計(jì)約束及確認(rèn)標(biāo)準(zhǔn)的形式化的、詳細(xì)的描述是必需要的。這些內(nèi)容只有通過用戶和開發(fā)者之間的通信交流才能確定。20軟件的神話用戶的神話神話：項(xiàng)目需求總是在不斷變化，但這些變化能夠很容易地滿足，因?yàn)檐浖庆`活的。事實(shí)：軟件需求確實(shí)是經(jīng)常變化的，但這些變化產(chǎn)生的影響會(huì)隨著其引入的時(shí)間不同而不同。如果我們很注重早期的系統(tǒng)定義，這時(shí)需求變化就可很容易地適應(yīng)。用戶能夠復(fù)審需求，并提出對(duì)修改建議，這時(shí)對(duì)成本的影響會(huì)相對(duì)較小。當(dāng)在軟件設(shè)計(jì)過程中才要求修改時(shí)，對(duì)成本的影響就會(huì)提高的很快

9、。資源已經(jīng)消耗了，設(shè)計(jì)框架已經(jīng)建立了，這時(shí)的變化可能會(huì)引起大的改動(dòng)，需要額外的資源和大量的設(shè)計(jì)修改：如額外的花費(fèi)。實(shí)現(xiàn)階段（編碼和測試階段）功能、性能、接口及其它方面的改變對(duì)成本會(huì)產(chǎn)生更大的影響。當(dāng)軟件已投入使用后再要求修改，這時(shí)所花費(fèi)的代價(jià)比起較早階段做同樣修改所花的代價(jià)可能是幾何級(jí)數(shù)級(jí)的增長。21例子 某公園有一游船碼頭，負(fù)責(zé)人請一位軟件開發(fā)人員實(shí)現(xiàn)計(jì)算機(jī)系統(tǒng)輔助游船管理系統(tǒng)，要求如下： 當(dāng)游客向租船處租船時(shí)，向租船處查詢是否有可租用的船只，如果租船處有空船，管理員就準(zhǔn)備好船只，幫助游客上船，并在聯(lián)機(jī)終端上打入一個(gè)信息“S”，表示租船周期開始。計(jì)算機(jī)自動(dòng)把當(dāng)時(shí)時(shí)鐘值送入信息域。當(dāng)游客還船時(shí)

10、，管理員打入另一個(gè)信息“E”，表示租船周期結(jié)束。由管理員向游客結(jié)算租船時(shí)間及費(fèi)用。一天結(jié)束時(shí)，管理員要用一些管理信息總結(jié)每天工作狀況，要求系統(tǒng)打印出 租船次數(shù)=NNN 平均租船時(shí)間=MMM 顯然，這樣一個(gè)系統(tǒng)的功能包括二個(gè)部分： 計(jì)算輸入流的信息 打印輸出22確定算法 我們知道平均租船時(shí)間就是總的時(shí)間除以租船次數(shù) 總的時(shí)間=第一條船結(jié)束時(shí)間 - 第一條船開始時(shí)間 + 第二條船結(jié)束時(shí)間 - 第二條船開始時(shí)間 + 或 總的時(shí)間=（第一條船結(jié)束時(shí)間 +第二條船結(jié)束時(shí)間 + ）-（第一條船開始時(shí)間 + 第二條船開始時(shí)間 + ）23編寫系統(tǒng)程序BEGIN OPEN MESSAGE_STREAM NUMB

11、ER=0 TOTALTIME=0 GET MESSAGE DO WHILE NOT END_OF_STREAM IF CODE=S THEN NUMBER=NUMBER+1 TOTAL_TIME=TOTAL_TIME-START_TIME ELSE TOTAL_TIME=TOTAL_TIME+END_TIME ENDIF PRINT “NUMBER OF SESSION =”NUMBER IF NUMBER0 THEN PRINT “AVERAGE SESSION TIME =”TOTAL_TIME/NUMBER ENDIF CLOSE MASSAGE_STREAMEND;24系統(tǒng)提出修改找出

12、一天中最長租用時(shí)間： LONGGEST_SESSION_TIME = PPP 要求把每天的報(bào)告分成兩個(gè)，一個(gè)是上午情況，另一個(gè)是下午情況 。通信線路出了毛病，丟掉了一些信息。要求修改系統(tǒng)-從計(jì)算報(bào)告中刪除一切不完整的租船信息。 對(duì)于上述的修改，除了把原系統(tǒng)廢棄之外。實(shí)在無法對(duì)其作什么修改來滿足這一新的要求。而時(shí)間及經(jīng)費(fèi)都不允許他這么做了。 結(jié)論：并不是任意設(shè)計(jì)出來的軟件都能夠適應(yīng)在軟件壽命期內(nèi)變化的要求，即軟件的靈活性不是絕對(duì)的。25軟件的神話開發(fā)者的神話 那些至今仍被軟件開發(fā)者相信的神話是由幾十年的程序設(shè)計(jì)文化培植起來的。而這種舊的觀念和方式是很難改變的。神話：一旦我們寫出了程序并使其正常運(yùn)

13、行，我們的工作就結(jié)束了。事實(shí)：有人說過：“越早開始寫程序，就要花越長的時(shí)間完成它”，大量的數(shù)據(jù)表明在一個(gè)程序上所投入的50%到70%的努力是花在第一次將程序交給用戶之后。26軟件的神話開發(fā)者的神話神話：在程序真正運(yùn)行之前，沒有辦法評(píng)估其質(zhì)量。事實(shí)：從項(xiàng)目一開始就可以應(yīng)用的最有效的軟件質(zhì)量保證機(jī)制之一是正式的技術(shù)復(fù)審。軟件復(fù)審是“質(zhì)量的過濾器”，比起通過測試找到某類軟件錯(cuò)誤要有效的多。神話：一個(gè)成功的項(xiàng)目唯一應(yīng)該提交的就是運(yùn)行程序。事實(shí)：運(yùn)行程序僅是仍軟件配置的一部分，軟件配置包括：程序、文檔和數(shù)據(jù)。文檔是成功開發(fā)的基礎(chǔ)，更重要的是，文檔為軟件維護(hù)提供了指導(dǎo)。27軟件危機(jī)解決途徑組織管理工程項(xiàng)目

14、管理方法技術(shù)措施軟件開發(fā)技術(shù)與方法軟件工具結(jié)論：按工程化的原則和方法組織軟件開發(fā)工作是必要的、有效的，也是擺脫軟件危機(jī)的一個(gè)主要出路。28軟件開發(fā)方法的發(fā)展?fàn)顩r隨意編程面向過程面向?qū)ο竺嫦蚪M件面向配置組件面向Web Service29計(jì)算機(jī)軟件發(fā)展的三個(gè)時(shí)期及特點(diǎn) 時(shí)間特點(diǎn)程 序 設(shè) 計(jì) 程 序 系 統(tǒng)軟 件 工 程軟件所指程序程序及說明書程序、文檔、數(shù)據(jù)、服務(wù)主要程序設(shè)計(jì)語言匯編及機(jī)器語言高級(jí)語言軟件語言軟件工作范圍程序編寫包括設(shè)計(jì)和測試軟件生存期需求者程序設(shè)計(jì)本人少數(shù)用戶市場用戶開發(fā)軟件的組織個(gè)人開發(fā)小組開發(fā)小組及大中型開發(fā)機(jī)構(gòu)軟件規(guī)模小型中小型大中小型決定質(zhì)量的因素個(gè)人程序技術(shù)小組技術(shù)水

15、平管理水平開發(fā)子程序程序庫結(jié)構(gòu)化程序設(shè)計(jì)數(shù)據(jù)庫、開發(fā)工具、開發(fā)環(huán)境、工程化開發(fā)方法、標(biāo)準(zhǔn)和規(guī)范、網(wǎng)絡(luò)和分布式開發(fā)、面向?qū)ο蠹夹g(shù)維護(hù)責(zé)任者程序設(shè)計(jì)者開發(fā)小組專職維護(hù)人員硬件特征價(jià)格高存儲(chǔ)容量小工作可靠性差降價(jià)、速度、容量及工作可靠性有明顯提高向超高速、大容量、微型化及網(wǎng)絡(luò)化方向發(fā)展軟件特征完全不受重視軟件技術(shù)的發(fā)展不能滿足需要，出現(xiàn)軟件危機(jī)開發(fā)技術(shù)有進(jìn)步，但未獲突破性進(jìn)展，價(jià)高，未完全擺脫軟件危機(jī)301.2 軟件工程31軟件工程的提出“軟件工程”一詞是1968年北大西洋公約組織（NATO）在聯(lián)邦德國召開的一次會(huì)議上首次提出的，這個(gè)會(huì)議專門討論了軟件危機(jī)問題。它反映了軟件人員認(rèn)識(shí)到軟件危機(jī)的出現(xiàn)及

16、謀求解決這一危機(jī)的努力，因此，這次會(huì)議被看作是軟件發(fā)展史上一個(gè)重要的里程碑。32軟件工程定義1968 年德國人 Bauer 在北大西洋公約組織會(huì)議上的定義： 建立并使用完善的工程化原則 , 以較經(jīng)濟(jì)的手段獲得能在實(shí)際機(jī)器上有效運(yùn)行的可靠軟件的一系列方法。1983 年 IEEE 的軟件工程定義： 軟件工程是開發(fā)，運(yùn)行 , 維護(hù)和修復(fù)軟件的系統(tǒng)方法。1993 年 IEEE 的一個(gè)更加綜合的定義： 將系統(tǒng)化的，規(guī)范的，可度量的方法應(yīng)用于軟件的開發(fā) , 運(yùn)行和維護(hù)的過程，即將工程化應(yīng)用于軟件中。33軟件工程定義軟件工程是指導(dǎo)軟件開發(fā)和維護(hù)的工程性學(xué)科，它以計(jì)算機(jī)科學(xué)理論和其他相關(guān)學(xué)科的理論為指導(dǎo)，采用

17、工程化的概念、原理、技術(shù)和方法進(jìn)行軟件的開發(fā)和維護(hù)，把經(jīng)過時(shí)間考驗(yàn)而證明是正確的管理技術(shù)和當(dāng)前能夠得到的最好的技術(shù)方法結(jié)合起來，以較少的代價(jià)獲得高質(zhì)量的軟件并維護(hù)它。簡言之： 工程方法+管理技術(shù)+技術(shù)方法+經(jīng)濟(jì)34軟件工程的框架可用性性開確正宜適選取適宜的開發(fā)范型采用合適的設(shè)計(jì)方法提供高質(zhì)量的支持工具重視開發(fā)過程的管理需求設(shè)計(jì)支持目標(biāo)活動(dòng)原則銷實(shí)現(xiàn)V&V35軟件工程的框架軟件工程框架給出了軟件工程三個(gè)主要方面。軟件工程目標(biāo)包括正確性、可用性和開銷適宜性，規(guī)定了軟件工程實(shí)踐的結(jié)果（即軟件）應(yīng)具有的基本性質(zhì)；軟件工程活動(dòng)包含的基本活動(dòng)有需求分析、設(shè)計(jì)、實(shí)現(xiàn)、驗(yàn)證與確認(rèn)及支持等活動(dòng)；軟件工程的四條原

18、則-采用適宜的開發(fā)范型，使用恰當(dāng)?shù)拈_發(fā)方法，提供高質(zhì)量的工具支持，實(shí)施有效的過程管理，從四個(gè)方面指導(dǎo)每一項(xiàng)工程的活動(dòng)，以實(shí)現(xiàn)軟件工程目標(biāo)。36軟件工程的知識(shí)體系指南2001年5月ISO/IEC JTC 1發(fā)布了 SWEBOK指南V0.95（試用版），即 Guide to the Software Engineering Body of Knowledge。SWEBOK把軟件工程學(xué)科的主體知識(shí)分為10個(gè)知識(shí)領(lǐng)域。這10個(gè)領(lǐng)域包括： 軟件需求 軟件設(shè)計(jì) 軟件構(gòu)造 軟件測試 軟件維護(hù) 軟件配置管理 軟件工程管理 軟件工程過程 軟件工程工具和方法 軟件質(zhì)量37軟件工程知識(shí)體系指南的目標(biāo) 促使軟件工程本

19、體知識(shí)成為世界范圍的共識(shí)。 澄清軟件工程與其他相關(guān)學(xué)科，如計(jì)算機(jī)科學(xué)、項(xiàng)目管理、計(jì)算機(jī)工程以及計(jì)算機(jī)數(shù)學(xué)的關(guān)系，并且確定軟件工程學(xué)科的范圍。 反映軟件工程學(xué)科內(nèi)容的特征。 確定軟件工程本體知識(shí)的各個(gè)專題。 為相應(yīng)的課程和職業(yè)資格認(rèn)證材料的編寫奠定基礎(chǔ)。38軟件工程知識(shí)體系指南的內(nèi)容39軟件工程知識(shí)體系指南的內(nèi)容知識(shí)域子 知 識(shí) 域子知識(shí)域/知識(shí)點(diǎn)（參考文獻(xiàn)）軟件需求軟件需求基礎(chǔ)、需求過程、需求獲取、需求分析、需求規(guī)格說明、需求確認(rèn)、實(shí)踐考慮7 / 28 ( 10 )軟件設(shè)計(jì)軟件設(shè)計(jì)基礎(chǔ)、軟件設(shè)計(jì)一關(guān)鍵問題、軟件結(jié)構(gòu)與體系結(jié)構(gòu)、軟件設(shè)計(jì)質(zhì)量的分析與評(píng)價(jià)、軟件設(shè)計(jì)符號(hào)、軟件設(shè)計(jì)的策略與方法6 /

20、25 ( 14 )軟件構(gòu)造軟件構(gòu)造基礎(chǔ)、管理構(gòu)造、實(shí)際考慮3 / 14 ( 7 ) 軟件測試軟件測試基礎(chǔ)、測試級(jí)別、測試技術(shù)、與測試相關(guān)的度量、測試過程5 / 16 ( 9 )軟件維護(hù)軟件維護(hù)基礎(chǔ)、軟件維護(hù)關(guān)鍵問題、維護(hù)過程、維護(hù)技術(shù)4 / 15 ( 16 )軟件配置管理軟件配置過程管理、軟件配置標(biāo)識(shí)、軟件配置控制、軟件配置狀態(tài)統(tǒng)計(jì)、軟件配置審計(jì)、軟件發(fā)行管理和交付6 / 7 ( 11 )軟件工程管理項(xiàng)目啟動(dòng)和范圍定義、軟件項(xiàng)目計(jì)劃、軟件項(xiàng)目實(shí)施、評(píng)審與評(píng)價(jià)、項(xiàng)目收尾、軟件工程度量6 / 24 ( 7 )軟件工程過程過程定義、過程實(shí)施與變更、過程評(píng)估、過程和產(chǎn)品度量4 / 16 ( 20 )軟

21、件工程工具和方法軟件工具（軟件需求工具、軟件設(shè)計(jì)工具、軟件構(gòu)造工具、軟件測試工具、軟件維護(hù)工具、軟件配置管理工具、軟件工程過程工具、軟件質(zhì)量工具和其他工具）軟件工程方法（啟發(fā)式方法、形式化方法、原型方法）2 / 2 ( 7 )軟件質(zhì)量軟件質(zhì)量基礎(chǔ)、軟件質(zhì)量過程、實(shí)踐考慮3 / 11 ( 68 )40軟件工程原則軟件工程原則有：1) 抽象與自頂向下、逐層細(xì)化 采用分層抽象的方法，有效控制軟件開發(fā)的復(fù)雜性。2) 模塊化 把問題分解為若干較小的較易解決的模塊，有助于信息隱蔽和抽象。3) 信息隱蔽和數(shù)據(jù)封裝 將模塊中的軟件設(shè)計(jì)決策封裝在模塊內(nèi)部，使得模塊實(shí)現(xiàn)與使用分離，有助于控制修改局部化。抽象與自頂

22、向下、逐層細(xì)化。41軟件工程的基本原理著名的軟件工程專家B.W.Boehm提出了軟件工程的七條基本原理。這七條原理是確保軟件產(chǎn)品質(zhì)量和開發(fā)效率的原理的最小集合。這七條原理是互相獨(dú)立的，其中任意六條原理的組合都不能代替另一條原理，因此，它們是缺一不可的最小集合，然而這七條原理又是相當(dāng)完備的，人們雖然不能用數(shù)學(xué)方法嚴(yán)格證明它們是一個(gè)完備的集合，但是，可以證明在此之前已經(jīng)提出的100多條軟件工程原理都可以由這七條原理的任意組合蘊(yùn)含或派生。42軟件工程的基本原理 用分階段的生命周期計(jì)劃嚴(yán)格管理 不成功的軟件項(xiàng)目中有一半左右是由于計(jì)劃不周造成的 。 堅(jiān)持進(jìn)行階段評(píng)審 軟件的質(zhì)量保證工作不能等到編碼階段結(jié)

23、束之后再進(jìn)行。 實(shí)行嚴(yán)格的產(chǎn)品控制 在軟件開發(fā)過程中不應(yīng)隨意改變需求，因?yàn)楦淖円豁?xiàng)需求往往需要付出較高的代價(jià)。 采用現(xiàn)代程序設(shè)計(jì)技術(shù) 采用先進(jìn)的技術(shù)既可提高軟件開發(fā)的效率，又可提高軟件維護(hù)的效率。 43軟件工程的基本原理 結(jié)果應(yīng)能清楚地審查 根據(jù)軟件開發(fā)項(xiàng)目的總目標(biāo)及完成期限，規(guī)定開發(fā)組織的責(zé)任和產(chǎn)品標(biāo)準(zhǔn)，從而使得所得到的結(jié)果能夠清楚地審查。 開發(fā)小組的人員應(yīng)該少而精 開發(fā)小組人員的素質(zhì)和數(shù)量是影響軟件產(chǎn)品質(zhì)量和開發(fā)效率的重要因素。小組人員增加，交流情況和討論問題而造成的通訊開銷也急劇增加，人數(shù)為N，可能的通訊路徑有N(N-1)/2。 承認(rèn)不斷改進(jìn)軟件工程實(shí)踐的必要性 不僅要積極主動(dòng)地采納新的

24、軟件技術(shù)，而且要注意不斷總結(jié)經(jīng)驗(yàn)。44軟件工程三要素軟件工程包括三要素：方法、工具和過程。 軟件工程方法為軟件開發(fā)提供了“如何做”的技術(shù)。 軟件工具為軟件工程方法提供了自動(dòng)的或半自動(dòng)的軟件支撐環(huán)境。 軟件工程的過程則是將軟件工程的方法和工具綜合起來以達(dá)到合理、及時(shí)地進(jìn)行計(jì)算機(jī)軟件開發(fā)的目的。45軟件工程項(xiàng)目的基本目標(biāo) 付出較低的成本； 達(dá)到要求的軟件功能； 取得較好的軟件性能； 開發(fā)的軟件易于移植； 需要較低的維護(hù)費(fèi)用； 能按時(shí)完成開發(fā)工作，及時(shí)交付使用。46軟件工程目標(biāo)之間的關(guān)系47軟件工程面臨的問題(1)軟件費(fèi)用(2)軟件可靠性(3)軟件維護(hù)(4)軟件生產(chǎn)率(5)軟件重用48軟件工程學(xué)的范

25、疇軟件工程學(xué)軟件工程技術(shù)軟件工程管理軟件開發(fā)方法學(xué)軟件工具軟件工程環(huán)境軟件經(jīng)濟(jì)學(xué)軟件管理學(xué)軟件心理學(xué)491.3 軟件生存周期與軟件過程50軟件生存周期的定義軟件生命周期的定義：軟件生命周期是指軟件產(chǎn)品從考慮其概念開始到該軟件產(chǎn)品不再能使用為止的整個(gè)時(shí)期。51劃分軟件生命周期的目的和實(shí)質(zhì) 便于控制開發(fā)工作的復(fù)雜性。 通過有限的步驟，把用戶的需求從抽象的邏輯概念逐步轉(zhuǎn)化為具體的物理實(shí)現(xiàn)。52軟件生存周期的基本任務(wù)軟件生命周期的基本任務(wù)可分為三個(gè)時(shí)期：即軟件定義、軟件開發(fā)和軟件運(yùn)行維護(hù)，每個(gè)時(shí)期又可劃分為若干任務(wù)。53軟件生命周期各時(shí)期的基本任務(wù)定義時(shí)期 定義時(shí)期主要集中于“做什么”，即在定義過程中

26、，軟件開發(fā)人員試圖弄清楚要處理什么信息，預(yù)期完成什么樣的功能和性能，希望有什么樣的系統(tǒng)行為，建立什么樣界面，有什么設(shè)計(jì)約束，以及定義一個(gè)成功系統(tǒng)的確認(rèn)標(biāo)準(zhǔn)是什么。在本階段需完成三項(xiàng)任務(wù)：54系統(tǒng)定義 系統(tǒng)定義必須回答的關(guān)鍵問題是：“要解決的問題是什么？”如果不知道問題是什么就試圖解決這個(gè)問題，顯然是盲目的，只會(huì)白白浪費(fèi)時(shí)間和金錢，最終得出的結(jié)果很可能是毫無意義的。盡管確切地定義問題的必要性是十分明顯的，但是在實(shí)踐中它卻可能是最容易被忽視的一個(gè)步驟。 系統(tǒng)定義是軟件生命周期中最簡短的任務(wù)，一般只需要一天甚至更少的時(shí)間。55可行性研究 可行性研究要回答的關(guān)鍵問題是：“對(duì)于上一個(gè)階段所確定的問題有行

27、得通的解決辦法嗎？”為了回答這個(gè)問題，系統(tǒng)分析員需要進(jìn)行一次大大壓縮和簡化了的系統(tǒng)分析和設(shè)計(jì)的過程，也就是在較抽象的高層次上進(jìn)行的分析和設(shè)計(jì)的過程?？尚行匝芯繎?yīng)該比較簡短，這個(gè)階段的任務(wù)不是具體解決問題，而是研究問題的范圍，探索這個(gè)問題是否值得去解，是否有可行的解決辦法。56需求分析 需求分析的任務(wù)仍然不是具體地解決問題，而是準(zhǔn)確地確定“為了解決這個(gè)問題，目標(biāo)系統(tǒng)必須做什么”，主要是確定目標(biāo)系統(tǒng)必須具備哪些功能。 系統(tǒng)分析員在需求分析階段必須和用戶密切配合，充分交流信息，以得出經(jīng)過用戶確認(rèn)的系統(tǒng)邏輯模型。通常用數(shù)據(jù)流圖、數(shù)據(jù)字典和簡要的算法表示系統(tǒng)的邏輯模型。57軟件生命周期各階段的基本任務(wù)開

28、發(fā)階段 開發(fā)階段集中于“如何做”。即在開發(fā)過程中，軟件工程師試圖定義數(shù)據(jù)如何結(jié)構(gòu)化，功能如何轉(zhuǎn)換為軟件體系結(jié)構(gòu)，過程細(xì)節(jié)如何實(shí)現(xiàn)，界面如何表示，設(shè)計(jì)如何轉(zhuǎn)換成程序設(shè)計(jì)語言，測試如何運(yùn)行。在本階段需完成四項(xiàng)任務(wù)：58總體設(shè)計(jì) 總體設(shè)計(jì)必須回答的關(guān)鍵問題是：“概括地說，應(yīng)該如何解決這個(gè)問題？” 通常至少應(yīng)該考慮下述幾類可能的方案： 低成本的解決方案。系統(tǒng)只能完成最必要的工作，不能多做一點(diǎn)額外的工作。 中等成本的解決方案。這樣的系統(tǒng)不僅能夠很好地完成預(yù)定的任務(wù)，使用起來很方便，而且可能還具有用戶沒有具體指定的某些功能和特點(diǎn)。雖然用戶沒有提出這些具體要求，但是系統(tǒng)分析員根據(jù)自己的知識(shí)和經(jīng)驗(yàn)斷定，這些附

29、加的能力在實(shí)踐中將證明是很有價(jià)值的。 高成本的“十全十美”的系統(tǒng)。這樣的系統(tǒng)具有用戶可能希望有的所有功能和特點(diǎn)。 59詳細(xì)設(shè)計(jì) 總體設(shè)計(jì)以比較抽象概括的方式提出了解決問題的辦法。詳細(xì)設(shè)計(jì)的任務(wù)就是把解法具體化，也就是回答下面這個(gè)關(guān)鍵問題：“應(yīng)該怎樣具體地實(shí)現(xiàn)這個(gè)系統(tǒng)呢？” 通常用HIPO圖（層次圖加輸入處理輸出圖）、PAD圖或PDL語言（過程設(shè)計(jì)語言）描述詳細(xì)設(shè)計(jì)的結(jié)果。60編碼和單元測試 編碼和單元測試的關(guān)鍵任務(wù)是寫出正確的容易理解、容易維護(hù)的程序模塊。61綜合測試 綜合測試的關(guān)鍵任務(wù)是通過各種類型的測試（及相應(yīng)的調(diào)試），使軟件達(dá)到預(yù)定的要求。 最基本的測試是集成測試和驗(yàn)收測試。所謂集成測試

30、是根據(jù)設(shè)計(jì)的軟件結(jié)構(gòu)，把經(jīng)過單元測試檢驗(yàn)的模塊按某種選定的策略裝配起來，在裝配過程中對(duì)程序進(jìn)行必要的測試。所謂驗(yàn)收測試則是按照規(guī)格說明書的規(guī)定（通常在需求分析階段確定），由用戶（或在用戶積極參加下）對(duì)目標(biāo)系統(tǒng)進(jìn)行驗(yàn)收。 必要時(shí)還可以再通過現(xiàn)場測試或平行運(yùn)行等方法對(duì)目標(biāo)系統(tǒng)進(jìn)一步測試檢驗(yàn)。 為了使用戶能夠積極參加驗(yàn)收測試，并且在系統(tǒng)投入生產(chǎn)性運(yùn)行以后能夠正確有效地使用這個(gè)系統(tǒng)，通常需要以正式的或非正式的方式對(duì)用戶進(jìn)行培訓(xùn)。62軟件生命周期各階段的基本任務(wù)軟件維護(hù) 維護(hù)階段的關(guān)鍵任務(wù)是，通過各種必要的維護(hù)活動(dòng)使系統(tǒng)持久地滿足用戶的需要。 通常有四類維護(hù)活動(dòng)：改正性維護(hù)，也就是診斷和改正在使用過程中

31、發(fā)現(xiàn)的軟件錯(cuò)誤；適應(yīng)性維護(hù)，即修改軟件以適應(yīng)環(huán)境的變化；完善性維護(hù)，即根據(jù)用戶的要求改進(jìn)或擴(kuò)充軟件使它更完善；預(yù)防性維護(hù)，即修改軟件為將來的維護(hù)活動(dòng)預(yù)先做準(zhǔn)備。 每一項(xiàng)維護(hù)活動(dòng)都應(yīng)該準(zhǔn)確地記錄下來，作為正式的文檔資料加以保存。63軟件生命周期各階段任務(wù)一覽表 階段 關(guān)鍵問題 結(jié)束標(biāo)準(zhǔn) 系統(tǒng)定義問題是什么？關(guān)于規(guī)模和目標(biāo)的報(bào)告書可行性研究有可行的解嗎？系統(tǒng)的高級(jí)邏輯模型；數(shù)據(jù)流圖成本效益分析需求分析系統(tǒng)必須做什么？系統(tǒng)的邏輯模型；數(shù)據(jù)流圖；數(shù)據(jù)字典；算法描述總體設(shè)計(jì)概括地說，應(yīng)該如何解決這個(gè)問題？可能的解法：系統(tǒng)流程圖；成本效益分析；推薦的系統(tǒng)結(jié)構(gòu)；層次圖或結(jié)構(gòu)圖詳細(xì)設(shè)計(jì)怎樣具體地實(shí)現(xiàn)這個(gè)系統(tǒng)？

32、編碼規(guī)格說明：HIPO圖或PDL編碼和單元測試正確的程序模塊源程序清單；單元測試方案和結(jié)果綜合測試符號(hào)要求的軟件綜合測試方案和結(jié)果；完整一致的軟件配置維護(hù)持久地滿足用戶需求的軟件完整準(zhǔn)確的維護(hù)記錄64什么是軟件工程過程定義：軟件工程過程是為獲得軟件產(chǎn)品，在軟件工具的支持下由軟件工程師完成的一系列軟件工程活動(dòng)。針對(duì)不同類型的軟件產(chǎn)品，同一軟件開發(fā)機(jī)構(gòu)也可能采用多個(gè)不同的軟件工程過程。65軟件工程過程的基本活動(dòng) 軟件規(guī)格說明：規(guī)定軟件的功能及其運(yùn)行的限制； 軟件開發(fā)：產(chǎn)生滿足規(guī)格說明的軟件； 軟件確認(rèn)：確認(rèn)軟件能夠完成客戶提出的要求； 軟件改進(jìn)：為滿足客戶的變更要求，軟件必須在使用的過程中改進(jìn)。6

33、6軟件工程過程的特性 易理解性。 可見性：每個(gè)過程活動(dòng)均能以明確的結(jié)果告終，使過程的進(jìn)展對(duì)外可見。 可支持性：易得到計(jì)算機(jī)輔助軟件工程（CASE）工具的支持。 可接受性：易于為軟件工程師接受和使用。 可靠性：不會(huì)出現(xiàn)過程錯(cuò)誤，或發(fā)現(xiàn)在產(chǎn)品出現(xiàn)故障之前。 健壯性：不受意外發(fā)生的問題干擾。 可維護(hù)性：過程可隨軟件機(jī)構(gòu)需求的變更或隨認(rèn)定的過程改進(jìn)而演進(jìn)。 速度：從規(guī)格說明起，就能較快地完成開發(fā)而交付。671.4 軟件過程模型68什么是軟件過程模型軟件過程模型也稱為軟件生存周期模型，它是對(duì)軟件過程的一種抽象表達(dá)。每個(gè)過程模型從某個(gè)特定視點(diǎn)描述了一個(gè)生存期過程，從而提供了有關(guān)該過程的特定的信息。軟件生存

34、周期模型是軟件工程思想的具體化，是跨越軟件生存周期的系統(tǒng)開發(fā)、運(yùn)行、維護(hù)所實(shí)施的全部活動(dòng)和任務(wù)的過程框架。常用的軟件生存周期模型有瀑布模型，演化模型，螺旋模型，增量模型，噴泉模型，快速應(yīng)用開發(fā)（ RAD ）模型。69編碼-修正模型在軟件開發(fā)早期，開發(fā)只有兩個(gè)階段，被簡單的分成編寫程序代碼和修改程序代碼。拿到項(xiàng)目，馬上就根據(jù)需要，開始編寫程序。編完代碼，調(diào)試通過，就算基本完成任務(wù)，拿給用戶用。如果應(yīng)用中有什么錯(cuò)誤，或有什么新的要求，要重新修改代碼。70編碼-修正模型的弊端1代碼缺少統(tǒng)一規(guī)劃，低估了設(shè)計(jì)的重要性，使得代碼結(jié)構(gòu)隨著修改的次數(shù)增加變得越來越壞。以至錯(cuò)誤越來越難改，甚至無法改。2即使有的

35、軟件計(jì)劃很好，但往往其結(jié)果并非用戶所需要的。造成軟件開發(fā)的風(fēng)險(xiǎn)非常大。這主要是沒有重視需求而造成的。3由于對(duì)測試、維護(hù)修改方面考慮不周，使得代碼維護(hù)修改非常困難。71瀑布模型由于吸取了開發(fā)早期的教訓(xùn)，人們開始將軟件開發(fā)視為工程來管理。類似于其他的工程管理，軟件開發(fā)也具有一定的工序。“軟件生命周期”這一概念真正被提了出來，并將軟件生命周期劃分成：制定計(jì)劃，需求分析、軟件設(shè)計(jì)、程序編寫、軟件測試、運(yùn)行與維護(hù)等六個(gè)部分。72瀑布模型73瀑布模型的特點(diǎn) 從上一項(xiàng)開發(fā)活動(dòng)接受該項(xiàng)活動(dòng)的工作對(duì)象，作為輸入。 利用這一輸入，實(shí)施該項(xiàng)活動(dòng)應(yīng)完成的工作內(nèi)容。 給出該項(xiàng)活動(dòng)的工作成果，作為輸出傳給下一項(xiàng)活動(dòng)。 對(duì)

36、該項(xiàng)目活動(dòng)實(shí)施的工作成果進(jìn)行評(píng)審。若工作得到確認(rèn)，則繼續(xù)進(jìn)行下一次開發(fā)活動(dòng)，否則返回前一項(xiàng)，甚至更前項(xiàng)的活動(dòng)。74瀑布模型優(yōu)點(diǎn) 消除非結(jié)構(gòu)化軟件。 降低軟件的復(fù)雜度。 促進(jìn)軟件開發(fā)工程化。75瀑布模型存在的問題 階段與階段劃分完全固定，階段間產(chǎn)生的大量文檔，極大地增加了工作量。 由于開發(fā)模型呈線性，所以當(dāng)開發(fā)成果尚未經(jīng)過測試時(shí)，用戶無法看到軟件的效果。這樣，軟件與用戶見面的時(shí)間較長，也增加了一定的風(fēng)險(xiǎn)。 前面未發(fā)現(xiàn)的錯(cuò)誤傳到后面的開發(fā)活動(dòng)中，可能會(huì)擴(kuò)散，進(jìn)而可能會(huì)造成更不理想的效果。76平行瀑布模型 考慮對(duì)瀑布模型的進(jìn)一步改進(jìn)。對(duì)瀑布模型的各階段之間的轉(zhuǎn)換時(shí)，不一定要求完全按順序進(jìn)行。而是以適

37、當(dāng)?shù)牟⑿虚_展各階段的工作。在上一階段尚未完成結(jié)束前，就可以開設(shè)后一階段的工作。 根據(jù)不同的情況可有不同的并行度： 用戶想法不穩(wěn)定，如：每天都變換想法，要求不太清楚的話，則增加并行度。 短期顯示成果的壓力大，則可增加并行度。 如果可靠性要求高；要求各方面控制和配合很嚴(yán)格；資源及預(yù)算嚴(yán)密；技術(shù)錯(cuò)誤的后果嚴(yán)重時(shí)，則需減少并行度。77快速原型模型 常有這種情況，用戶定義了軟件的一組一般性目標(biāo)，但不能標(biāo)識(shí)出詳細(xì)的輸入、處理及輸出需求；還有一情況，開發(fā)者可能不能確定算法的有效性、操作系統(tǒng)的適應(yīng)性或人機(jī)交換的形狀。在這些及很多情況下，快速原型模型可能是最好的選擇。 快速原型模型也稱為演進(jìn)模型，是基于快速開發(fā)

38、一個(gè)滿足初始構(gòu)想的模型的想法提出來的。78快速原型模型79快速原型模型需求的采集與細(xì)化客戶評(píng)價(jià)原型快速設(shè)計(jì)建造原型加工原型產(chǎn)生樣品停止開始80快速原型模型快速原型開發(fā)過程有兩種類型： 演進(jìn)開發(fā) - 過程的目的是與客戶一起工作，通過一次次向客戶演示原型系統(tǒng)并征求他們的意見，再根據(jù)他們的要求不斷改進(jìn)，從而演化出滿足客戶需求的可交付的最終系統(tǒng)。 廢棄原型 - 過程的目的是通過建立原型，借助原型與客戶溝通，探索與理解客戶的真正需求，據(jù)此開發(fā)出系統(tǒng)更良好的需求規(guī)格說明。原型是一種實(shí)驗(yàn)品，可參考它來開發(fā)最終系統(tǒng)，但不采取擴(kuò)充它以形成最終系統(tǒng)的辦法。原型起到這一作用后便廢棄。81快速原型模型的優(yōu)點(diǎn) 增進(jìn)軟件

39、人員和用戶對(duì)系統(tǒng)服務(wù)的理解，使比較含糊的、具有不確定的軟件需求明確化。 原型模型方法提供了一種有力的學(xué)習(xí)手段。 使用原型化方法可以容易地確定系統(tǒng)的性能，確認(rèn)各項(xiàng)主要系統(tǒng)服務(wù)的可應(yīng)用性，確認(rèn)系統(tǒng)設(shè)計(jì)的可行性，確認(rèn)系統(tǒng)作為產(chǎn)品的結(jié)果。 軟件原型的最終版本，有的可原封不動(dòng)地成為產(chǎn)品，有的略加修改，就可以成為最終系統(tǒng)的一個(gè)組成部分。82快速原型模型存在的問題過程是不可見的 - 管理人員要求提供正式的可交付的工作產(chǎn)品，用以測量開發(fā)進(jìn)度。如果系統(tǒng)是快速開發(fā)出來的，想要產(chǎn)生反映系統(tǒng)的每一個(gè)版本的文檔，其代價(jià)是高昂的。 系統(tǒng)常常構(gòu)造得不合理 - 持續(xù)的變更常常會(huì)惡化軟件結(jié)構(gòu)。組合軟件便更會(huì)增加修改軟件的困難、

40、提高成本?？赡芤筇厥獾墓ぞ吆图夹g(shù) - 這些工具和技術(shù)用于快速開發(fā)，但可能與其他工具或技術(shù)不兼容，而且可能只有相當(dāng)少的人具有使用這些工具或技術(shù)的技能。83形式化系統(tǒng)開發(fā)模型形式化系統(tǒng)開發(fā)模型是一種基于形式化數(shù)學(xué)變換的軟件開發(fā)方法，它可將系統(tǒng)規(guī)格說明轉(zhuǎn)換為可執(zhí)行的程序。該模型只適合于軟件的形式化開發(fā)方法；需要嚴(yán)格的數(shù)學(xué)理論和形式化技術(shù)支持；需要一整套開發(fā)環(huán)境（如程序變換工具、定理證明工具等）的支持。 84形式化系統(tǒng)開發(fā)模型與瀑布模型的主要區(qū)別 軟件需求規(guī)格說明被細(xì)化為用數(shù)學(xué)記號(hào)表達(dá)的、詳細(xì)的形式化規(guī)格說明。 設(shè)計(jì)、實(shí)現(xiàn)和單元測試等開發(fā)過程由一個(gè)變換開發(fā)過程代替。通過一系列變換將形式的規(guī)格說明細(xì)化

41、成為程序。85面向復(fù)用的開發(fā)模型如果將要開發(fā)的軟件的設(shè)計(jì)或代碼與已經(jīng)開發(fā)的項(xiàng)目有類似的情形，經(jīng)常會(huì)發(fā)生這種事情。開發(fā)人員尋找可復(fù)用的部分，按照要求加以修改以適應(yīng)新系統(tǒng)?；跇?gòu)件的軟件開發(fā)方法得到日益廣泛的應(yīng)用，它把復(fù)用嵌入到開發(fā)過程中，實(shí)現(xiàn)快速的系統(tǒng)開發(fā)。面向復(fù)用的方法通常依賴于一個(gè)大的可復(fù)用軟件構(gòu)件庫，這個(gè)構(gòu)件庫是一個(gè)框架，用以集成眾多的構(gòu)件，供使用者訪問。86面向復(fù)用的開發(fā)模型的主要任務(wù) 構(gòu)件分析 - 在已給定需求規(guī)格說明的情況下，搜索所有的構(gòu)件庫尋找可實(shí)現(xiàn)規(guī)格說明的構(gòu)件。 需求修改 - 使用已選定構(gòu)件的信息再分析需求，然后修改需求，使得這些構(gòu)件能夠有效地被利用。 考慮復(fù)用的系統(tǒng)設(shè)計(jì) -

42、設(shè)計(jì)系統(tǒng)的整體框架或復(fù)用一個(gè)已有的系統(tǒng)框架。 開發(fā)和集成 - 開發(fā)不能購進(jìn)的軟件，集成構(gòu)件和COTS系統(tǒng)，從而建立系統(tǒng)。87增量模型增量模型融合了線性順序模型的基本成分(重復(fù)地應(yīng)用)和原型的迭代特征。增量模型采用隨著日程時(shí)間的進(jìn)展而交錯(cuò)的線性序列。每一個(gè)線性序列產(chǎn)生軟件的一個(gè)可發(fā)布的“增量” 。增量模型是一種非整體開發(fā)的模型。軟件在該模型中是“逐漸”開發(fā)出來的。該模型有較大的靈活性，適合于軟件需求不明確、設(shè)計(jì)方案有一定風(fēng)險(xiǎn)的軟件項(xiàng)目。 88增量模型89增量模型的優(yōu)點(diǎn)客戶不必等到整個(gè)系統(tǒng)全部完成就能得到他們所需要的東西。第一個(gè)增量構(gòu)件滿足他們最關(guān)鍵的需求，這樣，軟件可以直接使用。客戶可以使用較早

43、的增量構(gòu)件作為原型，用于取得經(jīng)驗(yàn)，從而獲得稍后的增量構(gòu)件的需求。項(xiàng)目失敗的風(fēng)險(xiǎn)較低。雖然在某些增址構(gòu)件中可能遇到一些問題，但其他增量構(gòu)件將能夠成功地交付給客戶。優(yōu)先級(jí)最高的服務(wù)首先交付，然后再將其他增量構(gòu)件逐次集成進(jìn)來。一個(gè)必然的事實(shí)是：最重要的系統(tǒng)服務(wù)將接受最多的測試。這意味著系統(tǒng)最重要的部分一般不會(huì)遭遇失敗。90螺旋模型螺旋模型將瀑布模型與演化模型結(jié)合起來，并且加入兩種模型均忽略了的風(fēng)險(xiǎn)分析。螺旋模型沿著螺線旋轉(zhuǎn)，自內(nèi)向外每旋轉(zhuǎn)一圈便開發(fā)出更完善的一個(gè)新版本。 制定計(jì)劃確定軟件目標(biāo)，選定實(shí)施方案，弄清項(xiàng)目開發(fā)的限制條件； 風(fēng)險(xiǎn)分析分析所選方案，考慮如何識(shí)別風(fēng)險(xiǎn)和消除風(fēng)險(xiǎn)； 實(shí)施工程實(shí)施軟件

44、開發(fā)； 客戶評(píng)估評(píng)價(jià)開發(fā)工作，提出修正建議。91螺旋模型92噴泉模型體現(xiàn)了迭代和無間隙的特性。系統(tǒng)某個(gè)部分常常重復(fù)工作多次，相關(guān)對(duì)象在每次迭代中隨之加入演進(jìn)的軟件成分。無間隙是指在各項(xiàng)開發(fā)活動(dòng)，即分析、設(shè)計(jì)和編碼之間不存在明顯的邊界。噴泉模型是對(duì)象驅(qū)動(dòng)的過程。93噴泉模型需求階段分析階段設(shè)計(jì)階段編程階段集成與測試階段維護(hù)與演進(jìn)階段94噴泉模型的特點(diǎn)噴泉模型各階段相互重疊，反映了軟件過程并行性的特點(diǎn)。噴泉模型以分析為基礎(chǔ)，資源消耗呈塔形，在分析階段消耗的資源最多。噴泉模型反映了軟件過程迭代的自然特性，從高層返回低層沒有資源消耗。噴泉模型強(qiáng)詢增量式開發(fā)，它依據(jù)分析一部分就設(shè)計(jì)一部分的原則，不要求一

45、個(gè)階段的徹底完成。整個(gè)過程是一個(gè)迭代的、逐步細(xì)化的過程。噴泉模型是對(duì)象驅(qū)動(dòng)的過程，對(duì)象是所有活動(dòng)作用的實(shí)體，也是項(xiàng)目管理的基本內(nèi)容。噴泉模型在實(shí)現(xiàn)時(shí)，由于活動(dòng)不同，可分為對(duì)象實(shí)現(xiàn)和系統(tǒng)實(shí)現(xiàn)，不但反映了系統(tǒng)的開發(fā)全過程，而且也反映了對(duì)象族的開發(fā)和復(fù)用的過程。95智能模型智能模型是基于知識(shí)的軟件開發(fā)模型，它把瀑布模型和專家系統(tǒng)綜合在一起。該模型在各個(gè)開發(fā)階段都利用了相應(yīng)的專家系統(tǒng)來幫助軟件人員完成開發(fā)工作。96智能模型的優(yōu)點(diǎn)通過領(lǐng)域的專家系統(tǒng)，可使需求說明更完整、準(zhǔn)確和無二義性。通過軟件工程專家系統(tǒng)，提供一個(gè)設(shè)計(jì)庫支持，在開發(fā)過程中成為設(shè)計(jì)人員的助手。通過軟件工程知識(shí)和特定應(yīng)用領(lǐng)域知識(shí)和規(guī)則的應(yīng)用

46、幫助系統(tǒng)的開發(fā)。97快速應(yīng)用開發(fā)(RAD)模型快速應(yīng)用開發(fā)模型是一種增量開發(fā)模型，該模型開發(fā)軟件大量使用了可復(fù)用的構(gòu)件。每一個(gè)增量的開發(fā)經(jīng)歷五個(gè)階段：業(yè)務(wù)建模 對(duì)業(yè)務(wù)功能的信息流建模。數(shù)據(jù)建模 對(duì)業(yè)務(wù)的數(shù)據(jù)對(duì)象和關(guān)系建模。過程建模 描述完成業(yè)務(wù)功能的數(shù)據(jù)變換。應(yīng)用生成 應(yīng)用構(gòu)件和自動(dòng)化工具建造。測試與反復(fù) 對(duì)新構(gòu)件和接口進(jìn)行測試。98快速應(yīng)用開發(fā)(RAD)模型99快速應(yīng)用開發(fā)(RAD)模型的缺點(diǎn)對(duì)于大型的項(xiàng)目，為建立適當(dāng)數(shù)目的RAD開發(fā)小組可能需要大量的人力資源。如果開發(fā)人員和客戶雙方在短時(shí)間內(nèi)不能對(duì)整個(gè)系統(tǒng)的開發(fā)達(dá)成協(xié)議，或任何一方做不到的話，使用 RAD 進(jìn)行開發(fā)將不可避免地會(huì)遭到失敗。如果一個(gè)系統(tǒng)不能夠合理地模塊化，則構(gòu)造 RAD 構(gòu)件會(huì)出現(xiàn)問題