軟件工程軟件維護

軟件工程軟件維護第一頁，共七十八頁，編輯于2023年，星期三軟件維護的概念軟件維護分類軟件維護活動結構化維護和非結構化維護維護成本維護可能存在的問題軟件維護過程維護機構/組織維護流程軟件維護文檔維護的副作用軟件的可維護性軟件維護的新方法軟件工程——軟件維護

第二頁，共七十八頁，編輯于2023年，星期三第15章 軟件維護軟件維護是軟件生命周期的最后一個階段，軟件從部署完畢到退役的整個時間內對軟件的改動所做的工作都是維護的內容。在項目的各個階段對項目的可維護性進行充分考慮、對可維護性的嚴格評審以及在維護階段有效地組織和管理維護活動，則是保證軟件可維護性和降低維護費用的關鍵。本章重點內容：維護的主要內容、維護的流程、如何在軟件的生產過程各個階段保證軟件的可維護性目標。

第三頁，共七十八頁，編輯于2023年，星期三第十五章軟件維護軟件后期維護費用有時竟高達軟件總費用的80%，所有前期開發(fā)費用僅占20%。許多大型軟件公司為維護已有軟件耗費大量人力、財力。因此，必須建立一套評估、控制和實施軟件維護的機制。

第四頁，共七十八頁，編輯于2023年，星期三軟件維護概念是指在軟件的運行/維護階段由軟件廠商向客戶所提供的服務工作。三層含義（1）軟件的維護總是針對某一種軟件產品在軟件生存周期內所進行的活動

（2）當今的軟件維護更強調的是服務。在激烈的市場競爭中，同類軟件產品的價格、功能、性能和接口等都差不多，而服務就會成為用戶選購軟件的重要依據(jù)，即“賣軟件就是賣服務”（3）軟件維護的時間是有限度的，一般而言目前軟件產品的免費服務時間為兩年左右，兩年以后軟件廠商總會推出更新的版本以適應用戶在功能、性能、接口等方面所提出的新需求，從而軟件廠商也會找到新的利潤增長點。第五頁，共七十八頁，編輯于2023年，星期三主講內容軟件維護的分類維護活動軟件維護過程維護的副作用軟件的可維護性軟件再工程：逆向工程和重構工程

第六頁，共七十八頁，編輯于2023年，星期三15.1軟件維護的分類按照維護的起因分類：糾錯性維護適應性維護改善性維護/擴充與完善性維護預防性維護四類。1.糾錯性維護（CorrectiveMaintenance）——為改正軟件系統(tǒng)中潛藏的錯誤而進行的活動。用戶在使用軟件過程中發(fā)現(xiàn)軟件的錯誤是激發(fā)該種維護的起因。四類

第七頁，共七十八頁，編輯于2023年，星期三15.1軟件維護的分類2.適應性維護（AdaptiveMaintenance）——為適應軟件運行環(huán)境的變化而修改軟件的活動。軟件的運行環(huán)境包括兩個方面，硬件和軟件，軟件則大體上包括操作系統(tǒng)、中間件、虛擬機等等。

第八頁，共七十八頁，編輯于2023年，星期三15.1軟件維護的分類3.改善性維護（PerfectiveMaintenance）——根據(jù)用戶在軟件使用過程中提出的建設性意見而進行的維護活動。主要是針對用戶提出的新的軟件需求或修改原有的軟件需求而進行的維護，該種維護通常占所有維護工作量的一半以上。軟件在部署之后一段時間內，用戶的改善性維護應該是遞減的。

第九頁，共七十八頁，編輯于2023年，星期三15.1軟件維護的分類4.預防性維護（PreventiveMaintenance）——為了進一步改善軟件系統(tǒng)的可維護性和可靠性，并為以后的改進奠定基礎。預防性維護可以采取逆向工程（reverseengineering）和重構工程（re-engineering）方式。

第十頁，共七十八頁，編輯于2023年，星期三15.1軟件維護的分類預防性維護即軟件再工程，是為了提高軟件的可維護性、可靠性等，為以后進一步改進軟件打下良好基礎。預防性維護定義為：采用先進的軟件工程方法對需要維護的軟件或軟件中的某一部分（重新）進行設計、編制和測試。

第十一頁，共七十八頁，編輯于2023年，星期三軟件維護的種類完善性維護（perfectivemaintenance）完善和加強產品的功能與性能，以滿足用戶日益增長的需要。50%適應性維護（adaptivemaintenance）使軟件適應運行環(huán)境的變化。25%糾錯性維護（correctivemaintenance）糾正在開發(fā)期間未能發(fā)現(xiàn)的遺留錯誤。21%預防性維護（preventivemaintenance）4%為了進一步改善軟件的可靠性和易維護性，或者為將來的維護奠定更好的基礎而對軟件進行修改。

第十二頁，共七十八頁，編輯于2023年，星期三各類維護活動的根本目的是延長軟件生存期其它維護4%軟件生存周期軟件誕生計劃分析設計編碼測試運行和維護(簡稱維護)改善期穩(wěn)定期陳舊期1年-10年2個月-2年重構軟件工程周期15.1軟件維護的分類

第十三頁，共七十八頁，編輯于2023年，星期三軟件維護的概念軟件維護分類軟件維護活動結構化維護和非結構化維護維護成本維護可能存在的問題軟件維護過程維護機構/組織維護流程軟件維護文檔維護的副作用軟件的可維護性軟件維護的新方法軟件工程——軟件維護

第十四頁，共七十八頁，編輯于2023年，星期三15.2軟件維護活動軟件維護是一種繁瑣而又不可或缺的工作，由于維護通常要求維護人員在用戶現(xiàn)場進行，而且維護任務可能非常緊急，因此對現(xiàn)場維護人員的壓力很大。而且沒有絲毫的成就感。

第十五頁，共七十八頁，編輯于2023年，星期三15.2.1結構化維護與非結構化維護非結構化維護——軟件的配置中只有源代碼。由于沒有分析和設計文檔，無法對程序的功能進行反向追蹤，理解別人的代碼是很痛苦的事情。由于配置中沒有測試文檔，所以維護后的代碼無法進行回歸測試。因而導致程序的結構化被不斷的破壞，維護的質量無法得到保證。

第十六頁，共七十八頁，編輯于2023年，星期三15.2.1結構化維護與非結構化維護結構化維護——待維護的軟件的配置是完整的。用戶提出的維護申請用正向追蹤很容易從分析設計文檔追蹤直至代碼中，從而使維護人員很容易定位代碼的維護點。所以這種維護不會破壞軟件的結構。結構化維護不僅能減少維護的工作量，還能提高維護的質量。

第十七頁，共七十八頁，編輯于2023年，星期三15.2.1結構化與非結構化的維護

第十八頁，共七十八頁，編輯于2023年，星期三15.2.2維護成本20世紀70年代，軟件的維護費用約占軟件總預算的35~40%。80年代時，軟件維護費用進一步增加，約占軟件總預算的60%。近年來，該值已上升到80%左右。隨著軟件復雜性的不斷提高，軟件的維護難度越來越大。這不僅導致維護成本不斷增高，軟件生產率急劇下降，還會帶來其他方面的負面影響。

第十九頁，共七十八頁，編輯于2023年，星期三15.2.2維護成本其他因素也已經引起人們的注意。如：由于資源(人力、設備)優(yōu)先用于維護任務，影響新軟件系統(tǒng)的開發(fā)，可能會喪失機會；有時還要付出一些無形的代價，如某些貌似合理但實際不能滿足的維護請求將引起用戶不滿;在軟件維護過程中引入的潛在錯誤降低了軟件的質量;從開發(fā)小組中臨時抽調工程師從事維護工作沖擊正在進行的開發(fā)等等。最后，維護舊程序使生產率(按每人月代碼行或每人月功能點計算)大幅度下降。

第二十頁，共七十八頁，編輯于2023年，星期三15.2.2維護成本估算模型MP+Ke=(c-d)M

:維護工作總工作量P:生產性工作量K

:

經驗常數(shù)c:復雜度d:對該軟件熟悉程度的度量

第二十一頁，共七十八頁，編輯于2023年，星期三15.2.3維護可能存在的問題1）無法追蹤軟件的整個創(chuàng)建過程。2）無法追蹤軟件版本的進化過程。軟件交付使用后對軟件不斷修復和完善的過程，就是軟件版本的進化過程，每一次進化都會使軟件的主、次版本號增大。3）理解別人的程序非常困難。4）得不到開發(fā)人員的幫助。5）軟件配置不完整或不正確。6）分析和設計的缺陷。7）維護工作讓人沒有成就感。

第二十二頁，共七十八頁，編輯于2023年，星期三15.2.3維護可能存在的問題軟件維護中出現(xiàn)的大部分問題都可歸咎于軟件規(guī)劃和開發(fā)方法的缺陷。軟件開發(fā)時采用急功近利還是放眼未來的態(tài)度，對軟件維護影響極大。一般說來，軟件開發(fā)若不嚴格遵循軟件開發(fā)標準，軟件維護就會遇到許多困難。

第二十三頁，共七十八頁，編輯于2023年，星期三15.2.4影響軟件維護工作量的因素在軟件維護中，影響維護工作量的因素主要有以下六種：系統(tǒng)的大小 系統(tǒng)規(guī)模越大，其功能就越復雜，軟件維護的工作量也隨之增大。程序設計語言 使用功能強大的程序設計語言可以控制程序的規(guī)模。語言的功能越強，生成程序的模塊化和結構化程度越高，所需的指令數(shù)就越少，程序的可讀性越好。Tobecontinue……

第二十四頁，共七十八頁，編輯于2023年，星期三系統(tǒng)年齡 系統(tǒng)使用時間越長，所進行的修改就越多，而多次的修改可能造成系統(tǒng)結構混亂。由于維護人員經常更換，程序變得越來越難于理解，加之系統(tǒng)開發(fā)時文檔不齊全，或在長期的維護過程中文檔在許多地方與程序實現(xiàn)不一致，從而使維護變得十分困難。數(shù)據(jù)庫技術的應用 使用數(shù)據(jù)庫，可以簡單而有效地存儲、管理系統(tǒng)數(shù)據(jù)，還可以減少生成用戶報表應用軟件的維護工作量。Tobecontinue……

15.2.4影響軟件維護工作量的因素第二十五頁，共七十八頁，編輯于2023年，星期三先進的軟件開發(fā)技術

在軟件開發(fā)過程中，如果采用先進的分析設計技術和程序設計技術，如面向對象技術、復用技術等，可減少大量的維護工作量。其它一些因素 如應用的類型、數(shù)學模型、任務的難度、開關與標記、IF嵌套深度、索引或下標數(shù)等，對維護工作量也有影響。

15.2.4影響軟件維護工作量的因素第二十六頁，共七十八頁，編輯于2023年，星期三軟件維護的概念軟件維護分類軟件維護活動結構化維護和非結構化維護維護成本維護可能存在的問題軟件維護過程維護機構/組織維護流程軟件維護文檔維護的副作用軟件的可維護性軟件維護的新方法軟件工程——軟件維護

第二十七頁，共七十八頁，編輯于2023年，星期三15.3軟件維護過程軟件維護工作在維護申請?zhí)岢鲋熬烷_始了，它必須是一項有組織有制度的工作，包括：建立維護組織，強制報告和評估的過程；為每個維護申請確定標準化的事件序列；制定保存維護活動記錄的制度和有關復審及評估的標準。每項軟件維護活動的過程是：維護申請→制定維護計劃→進行維護活動→建立維護文檔→復審/評價維護

第二十八頁，共七十八頁，編輯于2023年，星期三維護策略為維護工作制訂流程所有維護必須先提交維護申請，維護申請必須規(guī)范軟件維護要有計劃在維護過程中需做維護記錄對源程序進行修改軟件配置的修改15.3軟件維護過程

第二十九頁，共七十八頁，編輯于2023年，星期三15.3軟件維護過程

15.3.1維護機構/組織

維護組織一般由維護員，維護管理員，系統(tǒng)管理員，修改控制決策機構，配置管理員組成。維護員——真正執(zhí)行維護的人員；維護管理員——協(xié)調維護活動的人員；系統(tǒng)管理員——系統(tǒng)的管理者；修改控制決策機構——決定一次維護的走向。修改控制和決策機構、用戶、系統(tǒng)管理員、維護人員之間不能跨越維護管理員進行溝通和采取行動。

第三十頁，共七十八頁，編輯于2023年，星期三15.3.1維護機構/組織

第三十一頁，共七十八頁，編輯于2023年，星期三15.3.1維護機構/組織除了較大的軟件開發(fā)公司外，一個軟件（產品）的維護工作，并不需要一定設立一個專門的維護組織機構。至少，在開發(fā)部門建立一個非正式的維護機構則是非常必要的。維護需求往往是隨機發(fā)生的。維護申請?zhí)峤唤o維護管理員，并由系統(tǒng)監(jiān)督員評價。如果系統(tǒng)監(jiān)督員做出需要維護的評價，維護負責人確定如何進行維護。在維護人員進行維護的過程中，配置管理員嚴格把關，控制維護的范圍，對軟件配置進行審計。

第三十二頁，共七十八頁，編輯于2023年，星期三15.3.2維護的報告與審核用戶提出的維護申請必須采用標準的格式，須填寫由維護人員制定的：維護申請單（MaintenanceRequestForm，MRF）或軟件問題報告單（SoftwareProblemReport，SPR）。如果是糾錯性維護，應填寫SPR。在填寫SPR時，用戶必須完整地記錄出錯信息（什么錯誤）和出錯場景（在什么情況下出現(xiàn)的錯誤）。其他種類的維護，要填MRF。在MRF中應該附加簡短的修改規(guī)格說明，也就是在需求規(guī)格說明書中應作哪些改動，比如增加功能或修改功能等。

第三十三頁，共七十八頁，編輯于2023年，星期三15.3.2維護的報告與審核維護管理員將MRF后之提交給系統(tǒng)管理員，并據(jù)此對軟件改動量作評估。系統(tǒng)管理員核準該維護申請后，維護組織內部要制定一個軟件修改報告單（SoftwareChangeReport，SCR），MRF并不是軟件文檔的配置項。而軟件修改的真正依據(jù)是SCR，其內容如下：

1）本次修改所需工作量；

2）本次維護活動的性質；

3）本次維護請求的優(yōu)先級；

4）本次修改的背景數(shù)據(jù)（來自于MRF或SPR的陳述）。將SCR提交給修改控制決策機構，作為維護進一步工作的依據(jù)。SCR是保證軟件版本進化可跟蹤性所必須的文檔。

第三十四頁，共七十八頁，編輯于2023年，星期三15.3.3維護過程的事件流用戶的維護請求提交給維護組織后的信息流程如圖15-4-2所示。收到維護請求后，維護組織首先要判斷維護的類型，即本次維護請求是糾錯性維護還是其他類型的維護。對于糾錯維護要啟動糾錯維護流程，如果是其他類型的維護則啟動適應性或改善性維護流程。用戶和維護組織有時會對維護的類型有不同的看法。

第三十五頁，共七十八頁，編輯于2023年，星期三15.3.3維護活動的事件流第三十六頁，共七十八頁，編輯于2023年，星期三軟件維護的實施步驟嚴重性評價錯誤分析優(yōu)先度評價維護過程配置復審問題分析區(qū)分類型糾錯項目表維護人員名單⊕⊕完善適應糾錯開發(fā)項目表⊕高低已修改的配置批準交付用戶的配置已修改的軟件測試**維護人員名單嚴重不嚴重⊕

第三十七頁，共七十八頁，編輯于2023年，星期三15.3.3維護過程的事件流⑴確認維護類型⑵實施維護⑶維護評審

第三十八頁，共七十八頁，編輯于2023年，星期三軟件維護的管理流程

維護修改建議

分析修改建議是否合理提交管理部門審查是否同意修改撤銷NYNY進行測試

提交管理部門審批是否批準更新主文檔Y

更新其他文檔

提交使用修改N第三十九頁，共七十八頁，編輯于2023年，星期三15.3.4保存維護記錄為了能夠很好地評價維護的有效性，必須詳細記錄軟件維護過程中的各種數(shù)據(jù)，這些數(shù)據(jù)包括：（1）程序標志；（2）源程序行數(shù)；（3）目標程序的指令條數(shù)；（4）所用的編程語言；（5）安裝程序的日期；（6）自安裝之日起程序運行的次數(shù)；（7）自安裝之日起程序失敗的次數(shù)；（8）程序修改處的層數(shù)和標志；

第四十頁，共七十八頁，編輯于2023年，星期三15.3.4保存維護記錄（9）因程序變動而增加和刪除的源程序行數(shù)；（10）每處改動所耗費的人時數(shù)；（11）程序改動的日期；（12）軟件工程師標志；（13）MRF的標志；（14）本次維護的類型；（15）維護開始和結束的日期；（16）用于本次維護累計的人時數(shù)；（17）執(zhí)行本次維護的純利潤。上述數(shù)據(jù)應保存到維護數(shù)據(jù)庫里，作為維護評價的依據(jù)。

第四十一頁，共七十八頁，編輯于2023年，星期三15.3.5評價維護活動通過每次維護活動的詳細記錄，可通過下面的指標度量維護的有效性：（1）程序運行的平均失效次數(shù)（失效次數(shù)／運行的次數(shù)）；（2）維護活動耗費的總人時數(shù)；（3）各種程序，及各種語言的平均變動數(shù)；（4）維護階段修改每條語句所花費的人時數(shù)；（5）維護每種語言的程序平均花費的人時數(shù)；（6）一張MRF的平均周轉時間；（7）各類維護請求的百分比。

第四十二頁，共七十八頁，編輯于2023年，星期三15.3.6軟件維護的實施軟件維護，最終落實在修改源程序和文檔上。為了正確、有效地修改源程序，通常要先分析和理解源程序，然后修改源程序，最后重新檢查和驗證源程序

第四十三頁，共七十八頁，編輯于2023年，星期三15.3.6軟件維護的實施修改源程序的三個步驟分析和理解程序修改程序重新驗證程序靜態(tài)確認計算機確認維護后的驗收

第四十四頁，共七十八頁，編輯于2023年，星期三軟件維護的概念軟件維護分類軟件維護活動結構化維護和非結構化維護維護成本維護可能存在的問題軟件維護過程維護機構/組織維護流程軟件維護文檔維護的副作用軟件的可維護性軟件維護的新方法軟件工程——軟件維護

第四十五頁，共七十八頁，編輯于2023年，星期三15.4維護的副作用軟件修改是一項很危險的工作，對一個復雜的邏輯過程，那怕做一項微小的改動，都可能引入潛在的錯誤，雖然設計文檔化和細致的回歸測試有助于排除錯誤，但是維護仍然會產生副作用。一次修改5-10個語句，成功率50%；一次修改40-50個語句，成功的可能性20%；每糾正一個錯誤平均需修改17條指令。

第四十六頁，共七十八頁，編輯于2023年，星期三15.4維護的副作用軟件修改是一項很危險的工作，對一個復雜的邏輯過程，那怕做一項微小的改動，都可能引入潛在的錯誤，雖然設計文檔化和細致的回歸測試有助于排除錯誤，但是維護仍然會產生副作用。軟件維護的副作用指，由于維護或在維護過程中其他一些不期望的行為引入的錯誤，副作用大致可分為三類:(1)代碼副作用(2)數(shù)據(jù)副作用(3)文檔的副作用

第四十七頁，共七十八頁，編輯于2023年，星期三15.4維護的副作用維護的副作用是指，由于維護或在維護過程中其他一些不期望的行為引入的錯誤。副作用可分三類：（1）代碼副作用—下面的修改最易引起副作用： ①修改或刪除子程序； ②修改或刪除語句標號； ③修改或刪除標識符； ④為提高程序效率而做的修改； ⑤修改邏輯操作符； ⑥由設計變動引起的代碼修改； ⑦修改分支處的判斷條件；代碼副作用大多數(shù)可在回歸測試中發(fā)現(xiàn)。

第四十八頁，共七十八頁，編輯于2023年，星期三15.4維護的副作用（2）數(shù)據(jù)副作用數(shù)據(jù)副作用是由于修改數(shù)據(jù)結構帶來的副作用。容易引起數(shù)據(jù)副作用的修改包括： ①局部和全局常量的再定義； ②記錄或文件格式的再定義； ③增減數(shù)據(jù)或是由于修改數(shù)據(jù)結構的定義導致數(shù)據(jù)結構長度的改變； ④修改全局數(shù)據(jù)； ⑤重新初始化控制標志和指針； ⑥重新排列I/O表或子程序參數(shù)表。設計文檔化有助于抑制數(shù)據(jù)副作用，在設計文檔中有關于數(shù)據(jù)結構的詳細描述和交叉訪問表。

第四十九頁，共七十八頁，編輯于2023年，星期三15.4維護的副作用（3）文檔副作用由于程序修改而沒有對文檔進行相應的修改引起文檔的副作用。必須保持文檔和程序的一致性。每次維護之后，再次交付軟件之前應仔細評審整個配置，這樣才能更好地減少文檔的副作用。

第五十頁，共七十八頁，編輯于2023年，星期三軟件維護的概念軟件維護分類軟件維護活動結構化維護和非結構化維護維護成本維護可能存在的問題軟件維護過程維護機構/組織維護流程軟件維護文檔維護的副作用軟件的可維護性軟件維護的新方法軟件工程——軟件維護

第五十一頁，共七十八頁，編輯于2023年，星期三15.5軟件的可維護性可維護性（maintainability）軟件的可維護性是指軟件被理解和被正確改動的難易程度。軟件的可維護性差是軟件維護工作量和費用激增的直接原因，因此在軟件工程的各個階段都要保證軟件具有較高可維護性，從而降低軟件維護成本，這是軟件工程的重要目標之一。

第五十二頁，共七十八頁，編輯于2023年，星期三15.5.1影響可維護性的因素軟件的可維護性主要受下面因素影響：（1）軟件的構造過程是否嚴格按照軟件工程的方法進行；（2）開發(fā)團隊是否訓練有素；（3）軟件的開發(fā)平臺（操作系統(tǒng)和開發(fā)語言）是否標準?？偨Y起來就是：開發(fā)團隊（人）是否使用了通用的工具采用標準的方法來構造軟件。

第五十三頁，共七十八頁，編輯于2023年，星期三15.5.2可維護性的度量通過維護記錄可間接度量可維護性。（1）問題、收集維護工具以及分析問題所用的時間；（2）形成修改說明書所用的時間；（3）修改設計和源代碼所用的時間；（4）測試所用時間；（5）復審所用時間；（6）完全恢復所用時間。以上時間越短則軟件的可維護性越好。

第五十四頁，共七十八頁，編輯于2023年，星期三15.5.3文檔與軟件的可維護性文檔文檔是影響軟件可維護性的決定因素。由于長期使用的大型軟件系統(tǒng)在使用過程中必然會經受多次修改，所以文檔比程序代碼更重要。文檔類型用戶文檔描述系統(tǒng)功能和使用方法，不關心這些功能是怎樣實現(xiàn)的；系統(tǒng)文檔描述系統(tǒng)設計、實現(xiàn)和測試等各方面的內容。

第五十五頁，共七十八頁，編輯于2023年，星期三15.5.3可維護性復審在軟件工程每一階段的復審中，可維護性都是一個重要的指標。在需求分析階段的復審中，應在規(guī)格說明書中對將來可能修改和可以改進的部分加以注明；在設計階段的復審中，應該從易于維護和提高設計總體質量的角度對設計進行全面評審；代碼復審主要審查代碼風格和內部文檔（程序注釋等）這兩個直接影響可維護性的因素。最后，每一階段性測試，直到軟件正式交付之前，都應該進行的預防性維護。正式的可維護性復審放在測試完成之后，稱為配置復審。目的是保證配置中所有成分的完整、一致、易于理解且便于修改控制。

第五十六頁，共七十八頁，編輯于2023年，星期三主講內容軟件維護的分類維護活動軟件維護過程維護的副作用軟件的可維護性軟件再工程：逆向工程和重構工程

第五十七頁，共七十八頁，編輯于2023年，星期三預防性維護開發(fā)和維護者不應等待用戶的維護申請,可先選擇以下類型程序作為預防性維護對象:預計若干年內將繼續(xù)使用的程序當今正成功使用的程序最近的將來要進行大修改和完善的程序15.6軟件再工程

第五十八頁，共七十八頁，編輯于2023年，星期三15.6軟件再工程怎樣維護老程序？（1）反復多次地做修改程序的嘗試，與不可見的設計及源代碼“頑強戰(zhàn)斗”，以實現(xiàn)所要求的修改；（2）通過仔細分析程序盡可能多地掌握程序的內部工作細節(jié)，以便更有效地修改它；（3）在深入理解原有設計的基礎上，用軟件工程方法重新設計、重新編碼和測試那些需要變更的軟件部分；（4）以軟件工程方法學為指導，對程序全部重新設計、重新編碼和測試，為此可以使用CASE工具（逆向工程和再工程工具）來幫助理解原有的設計預防性維護方法“把今天的方法學應用到昨天的系統(tǒng)上，以支持明天的需求?！?---Miller

第五十九頁，共七十八頁，編輯于2023年，星期三15.6軟件再工程事實原因（1）維護一行源代碼的代價可能是最初開發(fā)該行源代碼代價的14-40倍；（2）重新設計軟件體系結構（程序及數(shù)據(jù)結構）時使用了現(xiàn)代設計概念，它對將來的維護可能有很大的幫助；（3）由于現(xiàn)有的程序版本可作為軟件原型使用，開發(fā)生產率可大大高于平均水平；（4）用戶具有較多使用該軟件的經驗，因此，能夠很容易地搞清新的變更需求和變更的范圍；（5）利用逆向工程和再工程的工具，可以使一部分工作自動化；（6）在完成預防性維護的過程中可以建立起完整的軟件配置。

第六十頁，共七十八頁，編輯于2023年，星期三15.6軟件再工程逆向工程（reverseengineering）：指在軟件生存周期中，將軟件的某種形式描述轉換成更抽象形式的活動重構（restructuring）：指在同一抽象級別上轉換系統(tǒng)的描述形式。如把C++程序轉換成Java程序設計恢復（designrecovery）：指借助工具從已有程序中抽象出有關數(shù)據(jù)結構設計、總體結構設計和過程設計的信息。

第六十一頁，共七十八頁，編輯于2023年，星期三15.6軟件再工程1什么是軟件再工程

軟件再工程是一類軟件工程活動，是一個工程過程,它將逆向工程、重構和正向工程組合起來,將現(xiàn)存系統(tǒng)重新構造為新的形式。

第六十二頁，共七十八頁，編輯于2023年，星期三15.6軟件再工程ReverseEngineering解剖分析競爭對手或已有的老產品，以獲取產品的設計，制造機密。分析已有的程序（或某種形式的描述），將程序（或其它描述）轉換成某種更高級的，更易于理解的抽象形式。Re-Engineering在逆向工程所獲信息的基礎上修改或用新的、規(guī)范的工程方法重構已有的系統(tǒng)的一個新的版本。

第六十三頁，共七十八頁，編輯于2023年，星期三15.6軟件再工程2為什么軟件再工程在軟件復用中,有問題是與現(xiàn)有系統(tǒng)密切相關的例如:

現(xiàn)有軟件系統(tǒng)如何適應當前技術的發(fā)展及需求的變化,采用更易于理解的、適應變化的、可復用的系統(tǒng)軟件構架并提煉出可復用的軟件構件?

現(xiàn)存大量的遺產軟件系統(tǒng)(LegacySoftware)由于技術的發(fā)展,正逐漸退出使用,如何對這些系統(tǒng)進行挖掘、整理,得到有用的軟件構件?

已有的軟件構件隨著時間的流逝會逐漸變得不可使用,如何對它們進行維護,以延長其生命期,充分利用這些可復用構件?

第六十四頁，共七十八頁，編輯于2023年，星期三軟件再工程(SoftwareReengineering)正是解決上述問題的主要技術手段。再工程的基礎是系統(tǒng)理解,包括對運行系統(tǒng)、源代碼、設計、分析、文檔等的全面理解。但在很多情況下,由于各類文檔的丟失,只能對源代碼進行理解,即程序理解。

它能夠使我們：

增進對軟件的理解；

提高軟件自身的可維護性、復用性或演化性.軟件再工程比其它系統(tǒng)進化方法具有的絕對優(yōu)勢減少軟件演化風險降低成本第六十五頁，共七十八頁，編輯于2023年，星期三

需求規(guī)范軟件設計1程序正向工程逆向工程軟件設計2重構

設計恢復

15.6.1軟件再工程過程模型逆向工程和重構工程示意圖第六十六頁，共七十八頁，編輯于2023年，星期三代碼重構數(shù)據(jù)重構正向工程庫存目錄分析文檔重構逆向工程15.6.1軟件再工程過程模型

第六十七頁，共七十八頁，編輯于2023年，星期三15.6.2