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

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

2、業(yè)的開發(fā)方法。6.軟件是復(fù)雜的，人類能夠創(chuàng)造的最復(fù)雜的產(chǎn)物是計算機(jī)軟件。7.軟件成本相當(dāng)昂貴。8.相當(dāng)多的軟件工作涉及到社會因素。6軟件的分類1.按軟件的功能劃分 系統(tǒng)軟件操作系統(tǒng)數(shù)據(jù)庫管理系統(tǒng)設(shè)備驅(qū)動程序通信處理程序等7軟件的分類 支撐軟件文本編輯程序文件格式化程序磁盤向磁帶向數(shù)據(jù)傳輸?shù)某绦虺绦驇煜到y(tǒng)支持需求分析、設(shè)計、實現(xiàn)、測試和支持管理的軟件8軟件的分類 應(yīng)用軟件商業(yè)數(shù)據(jù)處理軟件工程與科學(xué)計算軟件計算機(jī)輔助設(shè)計制造軟件系統(tǒng)仿真軟件智能產(chǎn)品嵌入軟件醫(yī)療、制藥軟件事務(wù)管理、辦公自動化軟件計算機(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.按軟件工作方式劃分 實時處理軟件 交互式軟件 分時軟件 批處理軟件4.按軟件服務(wù)對象的范圍劃分 項目軟件 產(chǎn)品軟件11軟件的分類5.按軟件使用的頻度劃分僅供一次使用的軟件 頻繁使用的軟件6.按軟件的失效 高可靠性軟件。 一般可靠性軟件。12軟件的發(fā)展軟件的發(fā)展大體經(jīng)歷了如下三個階段： 程序設(shè)計階段，約為50至60年代 特點：依賴于個人編程技巧 ，開發(fā)不規(guī)范，開發(fā)成本難控制，其交付

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

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

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

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

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

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

10、，管理員打入另一個信息“E”，表示租船周期結(jié)束。由管理員向游客結(jié)算租船時間及費用。一天結(jié)束時，管理員要用一些管理信息總結(jié)每天工作狀況，要求系統(tǒng)打印出 租船次數(shù)=NNN 平均租船時間=MMM 顯然，這樣一個系統(tǒng)的功能包括二個部分： 計算輸入流的信息 打印輸出22確定算法 我們知道平均租船時間就是總的時間除以租船次數(shù) 總的時間=第一條船結(jié)束時間 - 第一條船開始時間 + 第二條船結(jié)束時間 - 第二條船開始時間 + 或 總的時間=（第一條船結(jié)束時間 +第二條船結(jié)束時間 + ）-（第一條船開始時間 + 第二條船開始時間 + ）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、一天中最長租用時間： LONGGEST_SESSION_TIME = PPP 要求把每天的報告分成兩個，一個是上午情況，另一個是下午情況 。通信線路出了毛病，丟掉了一些信息。要求修改系統(tǒng)-從計算報告中刪除一切不完整的租船信息。 對于上述的修改，除了把原系統(tǒng)廢棄之外。實在無法對其作什么修改來滿足這一新的要求。而時間及經(jīng)費都不允許他這么做了。 結(jié)論：并不是任意設(shè)計出來的軟件都能夠適應(yīng)在軟件壽命期內(nèi)變化的要求，即軟件的靈活性不是絕對的。25軟件的神話開發(fā)者的神話 那些至今仍被軟件開發(fā)者相信的神話是由幾十年的程序設(shè)計文化培植起來的。而這種舊的觀念和方式是很難改變的。神話：一旦我們寫出了程序并使其正常運

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

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

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

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

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

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

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

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

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

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

23、束之后再進(jìn)行。 實行嚴(yán)格的產(chǎn)品控制 在軟件開發(fā)過程中不應(yīng)隨意改變需求，因為改變一項需求往往需要付出較高的代價。 采用現(xiàn)代程序設(shè)計技術(shù) 采用先進(jìn)的技術(shù)既可提高軟件開發(fā)的效率，又可提高軟件維護(hù)的效率。 43軟件工程的基本原理 結(jié)果應(yīng)能清楚地審查 根據(jù)軟件開發(fā)項目的總目標(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)軟件工程實踐的必要性 不僅要積極主動地采納新的

24、軟件技術(shù)，而且要注意不斷總結(jié)經(jīng)驗。44軟件工程三要素軟件工程包括三要素：方法、工具和過程。 軟件工程方法為軟件開發(fā)提供了“如何做”的技術(shù)。 軟件工具為軟件工程方法提供了自動的或半自動的軟件支撐環(huán)境。 軟件工程的過程則是將軟件工程的方法和工具綜合起來以達(dá)到合理、及時地進(jìn)行計算機(jī)軟件開發(fā)的目的。45軟件工程項目的基本目標(biāo) 付出較低的成本； 達(dá)到要求的軟件功能； 取得較好的軟件性能； 開發(fā)的軟件易于移植； 需要較低的維護(hù)費用； 能按時完成開發(fā)工作，及時交付使用。46軟件工程目標(biāo)之間的關(guān)系47軟件工程面臨的問題(1)軟件費用(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)品不再能使用為止的整個時期。51劃分軟件生命周期的目的和實質(zhì) 便于控制開發(fā)工作的復(fù)雜性。 通過有限的步驟，把用戶的需求從抽象的邏輯概念逐步轉(zhuǎn)化為具體的物理實現(xiàn)。52軟件生存周期的基本任務(wù)軟件生命周期的基本任務(wù)可分為三個時期：即軟件定義、軟件開發(fā)和軟件運行維護(hù)，每個時期又可劃分為若干任務(wù)。53軟件生命周期各時期的基本任務(wù)定義時期 定義時期主要集中于“做什么”，即在定義過程中

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

27、得通的解決辦法嗎？”為了回答這個問題，系統(tǒng)分析員需要進(jìn)行一次大大壓縮和簡化了的系統(tǒng)分析和設(shè)計的過程，也就是在較抽象的高層次上進(jìn)行的分析和設(shè)計的過程?？尚行匝芯繎?yīng)該比較簡短，這個階段的任務(wù)不是具體解決問題，而是研究問題的范圍，探索這個問題是否值得去解，是否有可行的解決辦法。56需求分析 需求分析的任務(wù)仍然不是具體地解決問題，而是準(zhǔn)確地確定“為了解決這個問題，目標(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é)如何實現(xiàn)，界面如何表示，設(shè)計如何轉(zhuǎn)換成程序設(shè)計語言，測試如何運行。在本階段需完成四項任務(wù)：58總體設(shè)計 總體設(shè)計必須回答的關(guān)鍵問題是：“概括地說，應(yīng)該如何解決這個問題？” 通常至少應(yīng)該考慮下述幾類可能的方案： 低成本的解決方案。系統(tǒng)只能完成最必要的工作，不能多做一點額外的工作。 中等成本的解決方案。這樣的系統(tǒng)不僅能夠很好地完成預(yù)定的任務(wù)，使用起來很方便，而且可能還具有用戶沒有具體指定的某些功能和特點。雖然用戶沒有提出這些具體要求，但是系統(tǒng)分析員根據(jù)自己的知識和經(jīng)驗斷定，這些附

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

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

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

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

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

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

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

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

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

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

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

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é)記號表達(dá)的、詳細(xì)的形式化規(guī)格說明。 設(shè)計、實現(xiàn)和單元測試等開發(fā)過程由一個變換開發(fā)過程代替。通過一系列變換將形式的規(guī)格說明細(xì)化

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

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

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

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

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

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