課程名稱：軟件工程第25講班級：日期：教室：教學(xué)題目：第15章軟件維護教學(xué)目的：了解維護的概念，掌握四類維護，了解維護過程、軟件的可維護性。教學(xué)重點：維護的概念、維護過程、可維護性。教學(xué)難點：維護過程。教具：多媒體教室、電子教案作業(yè)：第一頁，共三十三頁。第15章 軟件維護軟件維護是軟件生命周期的最后一個階段，軟件從部署完畢到退役的整個時間內(nèi)對軟件的改動所做的工作都是維護的內(nèi)容。在項目的各個階段對項目的可維護性進行充分考慮、對可維護性的嚴(yán)格評審以及在維護階段有效地組織和管理維護活動，則是保證軟件可維護性和降低維護費用的關(guān)鍵。本章重點內(nèi)容：維護的主要內(nèi)容、維護的流程、如何在軟件的生產(chǎn)過程各個階段保證軟件的可維護性目標(biāo)。第二頁，共三十三頁。15.1軟件維護的基本內(nèi)容軟件維護的主要目標(biāo)是使已部署的軟件按照需求規(guī)格說明書的要求（或用戶的新需求）運行，這要求軟件不僅要滿足用戶所需要的各項功能需求，同時還要滿足用戶對軟件的非功能需求。軟件維護的基本內(nèi)容則包含了實現(xiàn)這些目標(biāo)所做的全部工作。第三頁，共三十三頁。15.2軟件維護的分類按照維護的起因分類：糾錯性維護適應(yīng)性維護改善性維護預(yù)防性維護四類。1.糾錯性維護——為改正軟件系統(tǒng)中潛藏的錯誤而進行的活動。用戶在使用軟件過程中發(fā)現(xiàn)軟件的錯誤是激發(fā)該種維護的起因。四類第四頁，共三十三頁。15.2軟件維護的分類2.適應(yīng)性維護——為適應(yīng)軟件運行環(huán)境的變化而修改軟件的活動。軟件的運行環(huán)境包括兩個方面，硬件和軟件，軟件則大體上包括操作系統(tǒng)、中間件、虛擬機等等。第五頁，共三十三頁。15.2軟件維護的分類3.改善性維護——根據(jù)用戶在軟件使用過程中提出的建設(shè)性意見而進行的維護活動。主要是針對用戶提出的新的軟件需求或修改原有的軟件需求而進行的維護，該種維護通常占所有維護工作量的一半以上。軟件在部署之后一段時間內(nèi)，用戶的改善性維護應(yīng)該是遞減的。第六頁，共三十三頁。15.2軟件維護的分類4.預(yù)防性維護——為了進一步改善軟件系統(tǒng)的可維護性和可靠性，并為以后的改進奠定基礎(chǔ)。預(yù)防性維護可以采取逆向工程（reverseengineering）和重構(gòu)工程（re-engineering）方式。第七頁，共三十三頁。15.2軟件維護的分類嚴(yán)格按照軟件工程標(biāo)準(zhǔn)生產(chǎn)的軟件產(chǎn)品在維護過程中糾錯性維護的工作量很低，不到總維護工作量的1／5。由于改善性維護和適應(yīng)性維護需要修改需求規(guī)格說明書，應(yīng)按照需求變更來進行管理，相當(dāng)于螺旋模型中的又一次迭代過程，因此工作量很大。第八頁，共三十三頁。15.3軟件維護的特點軟件維護是一種繁瑣而又不可或缺的工作，由于維護通常要求維護人員在用戶現(xiàn)場進行，而且維護任務(wù)可能非常緊急，因此對現(xiàn)場維護人員的壓力很大。而且沒有絲毫的成就感。第九頁，共三十三頁。15.3.1結(jié)構(gòu)化維護與非結(jié)構(gòu)化維護非結(jié)構(gòu)化維護——軟件的配置中只有源代碼。由于沒有分析和設(shè)計文檔，無法對程序的功能進行反向追蹤，理解別人的代碼是很痛苦的事情。由于配置中沒有測試文檔，所以維護后的代碼無法進行回歸測試。因而導(dǎo)致程序的結(jié)構(gòu)化被不斷的破壞，維護的質(zhì)量無法得到保證。第十頁，共三十三頁。15.3.1結(jié)構(gòu)化維護與非結(jié)構(gòu)化維護結(jié)構(gòu)化維護——待維護的軟件的配置是完整的。用戶提出的維護申請用正向追蹤很容易從分析設(shè)計文檔追蹤直至代碼中，從而使維護人員很容易定位代碼的維護點。所以這種維護不會破壞軟件的結(jié)構(gòu)。結(jié)構(gòu)化維護不僅能減少維護的工作量，還能提高維護的質(zhì)量。第十一頁，共三十三頁。圖15-3-1非結(jié)構(gòu)化維護和結(jié)構(gòu)化維護維護請求配置理解代碼功能理解？修改代碼測試復(fù)審理解設(shè)計方案規(guī)劃修改設(shè)計修改代碼測試復(fù)審交付使用軟件代碼第十二頁，共三十三頁。15.3.2維護成本20世紀(jì)70年代，軟件的維護費用約占軟件總預(yù)算的35~40%。80年代時，軟件維護費用進一步增加，約占軟件總預(yù)算的60%。近年來，該值已上升到80%左右。隨著軟件復(fù)雜性的不斷提高，軟件的維護難度越來越大。這不僅導(dǎo)致維護成本不斷增高，軟件生產(chǎn)率急劇下降，還會帶來其他方面的負(fù)面影響。第十三頁，共三十三頁。維護工作量的估算模型M＝P+Ke(c-d)其中：M：維護所用工作量；P：生產(chǎn)性工作量—分析評價、修改設(shè)計和代碼；Ke(c-d)：助動性工作量—理解文檔和代碼；K：經(jīng)驗常數(shù)；c：軟件的維護復(fù)雜度，由軟件本身的復(fù)雜度，軟件的設(shè)計質(zhì)量以及文檔化的程度等因素決定；d：維護人員對軟件的熟悉程度；可見維護工作量同軟件的維護復(fù)雜度成指數(shù)關(guān)系。第十四頁，共三十三頁。15.3.3維護可能存在的問題1）無法追蹤軟件的整個創(chuàng)建過程。2）無法追蹤軟件版本的進化過程。軟件交付使用后對軟件不斷修復(fù)和完善的過程，就是軟件版本的進化過程，每一次進化都會使軟件的主、次版本號增大。3）理解別人的程序非常困難。4）得不到開發(fā)人員的幫助。5）軟件配置不完整或不正確。6）分析和設(shè)計的缺陷。7）維護工作讓人沒有成就感。第十五頁，共三十三頁。15.4軟件維護過程

15.4.1維護組織

維護組織一般由維護員，維護管理員，系統(tǒng)管理員，修改控制決策機構(gòu)，配置管理員組成。維護員——真正執(zhí)行維護的人員；維護管理員——協(xié)調(diào)維護活動的人員；系統(tǒng)管理員——系統(tǒng)的管理者；修改控制決策機構(gòu)——決定一次維護的走向。修改控制和決策機構(gòu)、用戶、系統(tǒng)管理員、維護人員之間不能跨越維護管理員進行溝通和采取行動。第十六頁，共三十三頁。圖15-4-1維護組織信息流圖修改控制決策機構(gòu)系統(tǒng)管理員維護管理員維護員配置管理員維護申請單第十七頁，共三十三頁。維護流程用戶的維護請求激發(fā)了一次維護活動，用戶將維護申請?zhí)峤唤o維護管理員，維護管理員將該維護請求交給系統(tǒng)管理員對維護活動可能引起的軟件修改進行評估，并將評估結(jié)果反饋給維護管理員，維護管理員按照維護請求單制定軟件修改報告單并提交給修改決策機構(gòu)進行維護決策。修改決策機構(gòu)根據(jù)情況決定采取的行動（拒絕請求還是接收請求），并把結(jié)果反饋給維護管理員，如果允許維護，維護管理員將通知維護員執(zhí)行該次維護。第十八頁，共三十三頁。15.4.2維護的報告與審核用戶提出的維護申請必須采用標(biāo)準(zhǔn)的格式，須填寫由維護人員制定的：維護申請單（MaintenanceRequestForm，MRF）或軟件問題報告單（SoftwareProblemReport，SPR）。如果是糾錯性維護，應(yīng)填寫SPR。在填寫SPR時，用戶必須完整地記錄出錯信息（什么錯誤）和出錯場景（在什么情況下出現(xiàn)的錯誤）。其他種類的維護，要填MRF。在MRF中應(yīng)該附加簡短的修改規(guī)格說明，也就是在需求規(guī)格說明書中應(yīng)作哪些改動，比如增加功能或修改功能等。第十九頁，共三十三頁。15.4.2維護的報告與審核維護管理員將MRF后之提交給系統(tǒng)管理員，并據(jù)此對軟件改動量作評估。系統(tǒng)管理員核準(zhǔn)該維護申請后，維護組織內(nèi)部要制定一個軟件修改報告單（SoftwareChangeReport，SCR），MRF并不是軟件文檔的配置項。而軟件修改的真正依據(jù)是SCR，其內(nèi)容如下：1）本次修改所需工作量；2）本次維護活動的性質(zhì)；3）本次維護請求的優(yōu)先級；4）本次修改的背景數(shù)據(jù)（來自于MRF或SPR的陳述）。將SCR提交給修改控制決策機構(gòu)，作為維護進一步工作的依據(jù)。SCR是保證軟件版本進化可跟蹤性所必須的文檔。第二十頁，共三十三頁。15.4.3維護過程的事件流用戶的維護請求提交給維護組織后的信息流程如圖15-4-2所示。收到維護請求后，維護組織首先要判斷維護的類型，即本次維護請求是糾錯性維護還是其他類型的維護。對于糾錯維護要啟動糾錯維護流程，如果是其他類型的維護則啟動適應(yīng)性或改善性維護流程。用戶和維護組織有時會對維護的類型有不同的看法。第二十一頁，共三十三頁。圖15-4-2維護活動的事件流其他出錯維護請求類型“救火活動”當(dāng)排在隊列之首嚴(yán)重性按SE方法學(xué)規(guī)劃、組織、實施工程隊列中還有維護請求評估后分類評估后按優(yōu)先級在對列排隊通知請求者并說明原因資源用于開發(fā)新的軟件采取行動從維護請求隊列之首取一任務(wù)類型按優(yōu)先級在對列中排隊評估后按優(yōu)先級在隊列排隊是否適應(yīng)性改善性非常嚴(yán)重并不嚴(yán)重是否第二十二頁，共三十三頁。15.4.4保存維護記錄為了能夠很好地評價維護的有效性，必須詳細(xì)記錄軟件維護過程中的各種數(shù)據(jù)，這些數(shù)據(jù)包括：（1）程序標(biāo)志；（2）源程序行數(shù)；（3）目標(biāo)程序的指令條數(shù)；（4）所用的編程語言；（5）安裝程序的日期；（6）自安裝之日起程序運行的次數(shù)；（7）自安裝之日起程序失敗的次數(shù)；（8）程序修改處的層數(shù)和標(biāo)志；第二十三頁，共三十三頁。15.4.4保存維護記錄（9）因程序變動而增加和刪除的源程序行數(shù)；（10）每處改動所耗費的人時數(shù)；（11）程序改動的日期；（12）軟件工程師標(biāo)志；（13）MRF的標(biāo)志；（14）本次維護的類型；（15）維護開始和結(jié)束的日期；（16）用于本次維護累計的人時數(shù)；（17）執(zhí)行本次維護的純利潤。上述數(shù)據(jù)應(yīng)保存到維護數(shù)據(jù)庫里，作為維護評價的依據(jù)。第二十四頁，共三十三頁。15.4.5評價維護活動通過每次維護活動的詳細(xì)記錄，可通過下面的指標(biāo)度量維護的有效性：（1）程序運行的平均失效次數(shù)（失效次數(shù)／運行的次數(shù)）；（2）維護活動耗費的總?cè)藭r數(shù)；（3）各種程序，及各種語言的平均變動數(shù)；（4）維護階段修改每條語句所花費的人時數(shù)；（5）維護每種語言的程序平均花費的人時數(shù)；（6）一張MRF的平均周轉(zhuǎn)時間；（7）各類維護請求的百分比。第二十五頁，共三十三頁。15.5維護的副作用維護的副作用是指，由于維護或在維護過程中其他一些不期望的行為引入的錯誤。副作用可分三類：（1）代碼副作用—下面的修改最易引起副作用：①修改或刪除子程序；②修改或刪除語句標(biāo)號；③修改或刪除標(biāo)識符；④為提高程序效率而做的修改；⑤修改邏輯操作符；⑥由設(shè)計變動引起的代碼修改；⑦修改分支處的判斷條件；代碼副作用大多數(shù)可在回歸測試中發(fā)現(xiàn)。第二十六頁，共三十三頁。15.5維護的副作用（2）數(shù)據(jù)副作用數(shù)據(jù)副作用是由于修改數(shù)據(jù)結(jié)構(gòu)帶來的副作用。容易引起數(shù)據(jù)副作用的修改包括：①局部和全局常量的再定義；②記錄或文件格式的再定義；③增減數(shù)據(jù)或是由于修改數(shù)據(jù)結(jié)構(gòu)的定義導(dǎo)致數(shù)據(jù)結(jié)構(gòu)長度的改變；④修改全局?jǐn)?shù)據(jù)；⑤重新初始化控制標(biāo)志和指針；⑥重新排列I/O表或子程序參數(shù)表。設(shè)計文檔化有助于抑制數(shù)據(jù)副作用，在設(shè)計文檔中有關(guān)于數(shù)據(jù)結(jié)構(gòu)的詳細(xì)描述和交叉訪問表。第二十七頁，共三十三頁。15.5維護的副作用（3）文檔副作用由于程序修改而沒有對文檔進行相應(yīng)的修改引起文檔的副作用。必須保持文檔和程序的一致性。每次維護之后，再次交付軟件之前應(yīng)仔細(xì)評審整個配置，這樣才能更好地減少文檔的副作用。第二十八頁，共三十三頁。15.6軟件的可維護性軟件的可維護性是指軟件被理解和被正確改動的難易程度。軟件的可維護性差是軟件維護工作量和費用激增的直接原因，因此在軟件工程的各個階段都要保證軟件具有較高可維護性，從而降低軟件維護成本，這是軟件工程的重要目標(biāo)之一。第二十九頁，共三十三頁。15.6.1影響可維護性的因素軟件的可維護性主要受下面因素影響：（1）軟件的構(gòu)造過程是否嚴(yán)格按照軟件工程的方法進行；（2）開發(fā)團隊是否訓(xùn)練有素；（3）軟件的開發(fā)平臺（操作系統(tǒng)和開發(fā)語言）是否標(biāo)準(zhǔn)?？偨Y(jié)起來就是：開發(fā)團隊（人）是否使用了通用的工具采用標(biāo)準(zhǔn)的方法來構(gòu)造軟件。第三十頁，共三十三頁。15.6.2可維護性的度量通過維護記錄可間接度量可維護性。（1）問題、收集維護工具以及分析問題所用的時間；（2）形成修改說明書所用的時間；（3）修改設(shè)計和源代碼所用的時間；（4）測試所用時間；（5）復(fù)審所用時間；（6）完全恢復(fù)所用時間。以上時間越