軟件工程012024/5/16第8章維護軟件產品被開發出來并交付用戶使用之后，就進入了軟件的運行維護階段。軟件生命周期的最后一個階段，其基本任務是保證軟件在一個相當長的時期能夠正常運行。平均來說，維護成本高達開發成本的4倍左右。目前國外許多軟件開發組織把60%以上的人力用于維護已有的軟件。軟件工程的主要目的就是提高軟件的可維護性，減少軟件維護所需要的工作量，降低軟件系統總成本。22024/5/16第8章維護軟件維護的定義01軟件維護的特點02軟件維護過程03軟件的可維護性04預防性維護05軟件再工程過程06小結0732024/5/168.1軟件維護的定義1所謂軟件維護，就是在軟件已經交付使用之后，為了改正錯誤或滿足新的需求而修改軟件的過程。2改正性維護：在大型程序的使用期間，用戶必然會發現程序錯誤，并且把他們遇到的問題報告給維護人員。把診斷和改正錯誤的過程稱為改正性維護。3適應性維護：為了和變化了的環境適當的配合而進行的修改軟件的活動。4完善性維護：在使用軟件的過程中，用戶往往提出增加新功能或修改已有功能的建議，還可能提出一般性的改進意見。5預防性維護：為了改進未來的可維護性或可靠性，或為了給未來的改進奠定更好的基礎而修改軟件。42024/5/168.1軟件維護的定義因此，維護絕不僅限于糾正使用中發現的錯誤。完善性維護：50-66%改正性維護：17-21%適應性維護：18-25%其他維護：4%上述4類維護活動都必須應用于整個軟件配置，維護軟件文檔和維護軟件的可執行代碼同樣重要。52024/5/168.2軟件維護的特點8.2.1結構化維護與非結構化維護差別巨大非結構化維護如果軟件配置的唯一成分是程序代碼，那么維護活動將非常艱難。評價程序代碼對于軟件結果、全程數據結構、系統接口、性能和（或）設計約束對程序代碼所做改動的后果也難于估量非結構化維護需要付出很大的代價，這種維護方式是沒有使用良好定義的方法學開發出來的軟件的必然結果62024/5/16結構化維護如果有一個完整的軟件配置存在，那么維護工作從評價軟件設計文檔開始。確定軟件重要的結構特點、性能特點以及接口特點；估量要求的改動將帶來的影響；然后首先修改設計并且對所做的修改進行仔細復查；接下來修改程序源碼；進行回歸測試；提交修改后的軟件8.2軟件維護的特點72024/5/168.2軟件維護的特點8.2.2維護的代價高昂維護費用穩步上升1970年，35%-40%1980年，40%-60%1990年，70%-80%可用資源的使用不能及時修改，引起用戶不滿引入潛伏錯誤，降低軟件質量開發人員作為維護人員，使得開發過程混亂生產率大幅度下降82024/5/168.2軟件維護的特點用于維護工作的勞動生產性活動（分析評價，修改設計，編寫程序代碼）非生產性活動（理解程序代碼的功能，解釋數據結構、接口特點和性能限度等）維護工作量模型：M維護用的總工作量，P生產性工作量，K經驗常數，c是復雜程度，d是維護人員對軟件的熟悉程度。92024/5/168.2軟件維護的特點絕大多數軟件在設計時沒有考慮將來的修改。需要維護的軟件往往沒有合格的文檔維護的問題，大部分都可歸因于軟件定義和軟件開發的方法有缺點。軟件維護不是一項吸引人的工作。當要求對軟件進行維護時，不能指望由開發人員給人們仔細說明軟件。8.2.3維護的問題很多理解別人寫的程序通常非常困難。102024/5/168.3軟件維護過程維護過程本質上是修改和壓縮了的軟件定義和開發過程，而且事實上遠在提出一項維護要求之前，與軟件維護有關的工作就已經開始了。建立維護組織確定報告和評價的過程為每個維護要求規定一個標準化的事件序列建立一個使用于維護活動的記錄保管過程規定復審標準112024/5/168.3軟件維護過程維護組織每個維護要求都通過維護管理員轉交給熟悉該產品的系統管理員去評論。維護活動開始之前就明確維護責任是十分必要的，這樣做可以大大減少維護過程中可能出現的混亂。122.維護報告應該用標準化的格式表達所有軟件的維護要求。給用戶提供空白的維護要求表。如果遇到了一個錯誤，必須完整的描述導致出現錯的環境輸入數據全部輸出其他有關信息2024/5/168.3軟件維護過程#202213對于適應性或完善性的維護要求，應該提一個簡短的需求說明書軟件組織內部應該制定出一個軟件修改報告：滿足維護要求表中提出的要求所需要的工作量維護要求的性質這項要求的優先次序與修改有關的時候數據2024/5/168.3軟件維護過程#2022142024/5/168.3軟件維護過程維護的事件流15不管維護的類型如何，都需要進行同樣的技術工作。這些工作包括修改軟件設計、復查、必要的代碼修改、單元和集成測試（包括回歸測試）、驗收測試和復審。當惡性軟件問題發生時，必須立即解決，這就是所謂的“救火”維護要求。在完成軟件維護任務之后，進行處境復查在當前處境下設計、編碼和測試的哪些方面能用不通的方法進行？哪些維護資源是應該有而事實上沒有的？對于這項維護工作什么是主要（以及次要）的障礙？要求的維護類型中有預防性維護嗎？2024/5/168.3軟件維護過程#2022164.保存維護記錄5.評價維護活動每次程序運行平均失效的次數用于每一類維護活動的總人時數平均每個程序、每種語言、每種維護類型所做的程序變動數維護過程中增加或刪除一個源語句平均花費的人時數維護每種語言平均話費的人時數一張維護要求表的平均周轉時間不同維護類型所占的百分比2024/5/168.3軟件維護過程#2022172024/5/168.4軟件的可維護性軟件的可維護性——維護人員理解、改正、改動或改進這個軟件的難易程度。軟件的可維護性是支配軟件工程方法學所有步驟的關鍵目標。8.4.1決定軟件可維護性的因素理解待修改的對象調試以確定錯誤的具體位置（改正性維護）進行必要的測試182024/5/168.4軟件的可維護性可理解性外來讀者理解軟件的結構、功能、接口和內部處理的難易程度。模塊化詳細的設計文檔結構化設計程序內部的文檔良好的高級程序設計語言192024/5/168.4軟件的可維護性可測試性良好的文檔對診斷和測試是至關重要的。軟件結構可用的測試工具和調試工具以前設計的測試過程開發階段用過的測試方案模塊的環形復雜度越大，可執行的路徑就越多，全面測試它的難度就越高202024/5/168.4軟件的可維護性可修改性耦合、內聚、信息隱藏、局部化、控制域和作用域的關系等，都影響軟件的可修改性。可移植性把程序從一種計算環境（硬件配置和操作系統）轉移到另一種計算環境的難易程度。把因環境變化而必須修改的程序局限在少數程序模塊中，從而降低修改的難度。212024/5/168.4軟件的可維護性可重用性同一個事物不做修改或稍加修改就在不同環境中多次重復使用。通常，可重用的軟件構件在開發時都經過很嚴格的測試，可靠性比較高。很容易修改可重用的軟件構件使之再次應用在新環境中。因此，軟件中使用的可重用構件越多，適應性和完善性維護也就越容易。222024/5/168.4軟件的可維護性8.4.2文檔文檔是影響軟件可靠性的決定因素。文檔比程序代碼更重要。文檔可分為用戶文檔和系統文檔兩類。用戶文檔主要描述系統功能和使用方法系統文檔描述系統設計、實現和測試等各個方面的內容。232024/5/168.4軟件的可維護性添加標題軟件文檔應該滿足下述要求。添加標題必須描述如何使用這個系統添加標題必須描述怎樣安裝和管理這個系統添加標題必須描述系統需求和設計添加標題必須描述系統的實現和測試添加標題用戶文檔添加標題能使用戶獲得對系統的準確的初步印象添加標題功能描述、安裝文檔、使用手冊、參考手冊、操作員指南242024/5/168.4軟件的可維護性系統文檔從問題定義、需求說明到驗收測試計劃這樣一些列和系統實現有關的文檔。把讀者從對系統概貌的了解，引導到對系統每個方面各個特點的更形式化更具體的認識。252024/5/168.4軟件的可維護性8.4.3可維護性復審在軟件工程過程的每個階段都應該考慮并努力提高軟件的可維護性，在每個階段結束前的技術審查和管理復審中，應該著重對可維護性進行復審。需求分析階段的復審對將來要改進的部分和可能會修改的部分加以注意并指明應該討論軟件的可移植性問題考慮可能影響軟件維護的系統界面262024/5/168.4軟件的可維護性設計復審從容易修改、模塊化和功能獨立的目標出發，評價軟件的結構和過程對將來可能修改的部分預作準備代碼復審編碼風格內部說明文檔盡量使用可重用的軟件構件272024/5/168.4軟件的可維護性01測試階段復審02配置復審03保證軟件配置的所有成分是完整的、一致的和可理解的04為了便于修改和管理已經編目歸檔了05完成了每項維護工作之后，都應該對軟件維護本身進行仔細的復審06維護應該針對整個軟件配置，不應該只修改源程序代碼07對設計、數據、模塊過程的修改體現在技術文檔中08對可執行部分的修改反映在用戶文檔中28幾乎所有歷史比較悠久的軟件開發組織，都有一些十幾年前開發出的“老”程序。目前，某些老程序仍然在為用戶服務，但是，這些程序的體系結構、數據結構可能很差，文檔可能并不完整，做過的修改可能并沒有記錄。滿足用戶對上述老程序的維護：反復多次地修改程序的嘗試通過仔細分析程序盡可能多地掌握程序的內部工作細節，以便有效修改它用軟件工程的方法重新設計、重新編碼和測試那些需要變更的軟件部分對程序全部重新設計、重新編碼和測試2024/5/168.5預防性維護#202229預防性維護由Miller提出來的，“把今天的方法學應用到昨天的系統上，以支持明天的需求”。維護一行源代碼的代價可能是最初來發該行代碼代價的14~40倍重新設計軟件體系結構時試用了現代設計概念，它將對維護可能有很大的幫助由于現有程序版本可作為軟件原型使用，開發生產可大大高于平均水平用戶具有較多使用該軟件的經驗，因此，能夠很容易地搞清新的變更需求和變更的范圍利用逆向工程和再工程的工具，可以使一部分工作自動化在完成預防性維護的過程中可以建立完整的軟件配置2024/5/168.5預防性維護#2022302024/5/168.6軟件再工程過程圖8.2軟件再工程過程模型312024/5/168.6軟件再工程過程庫存目錄分析每個軟件組織都應該保存其擁有的所有應用系統的庫存目錄。該目錄包含關于每個應用系統的基本信息。下列3類程序有可能成為預防性維護的對象：預定將使用多年的程序當前正在成功使用著的程序在最近的將來可能要做重大修改或增強的程序。應該仔細分析庫存目錄，按照業務重要程度、壽命、當前可維護性、預期的修改次數等標準，把庫中的應用系統排序，從中選出再工程的候選者，然后明智地分配再工程所需要的資源322024/5/168.6軟件再工程過程文檔重構建立文檔非常耗費時間，不可能為數百個程序都重新建立文檔。由于資源有限，應采用“使用時建立文檔”的方法。如果某應用系統是完成業務工作的關鍵，而且必須重構全部分檔，則仍然應該設法把文檔工作減少到必需的最小量。332024/5/168.6軟件再工程過程逆向工程軟件的逆向工程是分析程序以便在比源代碼更高的抽象層次上創建出程序的某種表示的過程。逆向工程是一個恢復設計結果的過程。從現存的程序代碼中抽取有關數據、體系結構、處理過程的設計信息。342024/5/168.6軟件再工程過程代碼重構首先用重構工具分析源代碼，標注出和結構化程序設計概念相違背的部分。然后重構有問題的代碼。最后，復審和測試生成的重構代碼并更新代碼文檔。重構關注個體模塊的設計細節以及在模塊中定義的局部數據結構。如果重構擴展到邊界之外并涉及軟件體系結構，則重構變成了正向工程。352024/5/168.6軟件再工程過程數據重構數據重構發生在向當低的抽象層次上，它是一種全范圍的再工程活動。數據結構始于逆向工程活動，分解當前使用的數據體系結構，必要時定義數據模型，標識數據對象和屬性，并從軟件質量的角度復審現存的數據結構。當數據結構較差時，應該對數據進行再工程。對數據的修改必然會導致體系結構或代碼層的改變。362024/5/168.6軟件再工程過程正向工程正向工程也成為革新或改造這項活動不僅從現有程序中恢復設計信息，而且使用該信息去改變或重構現有系統，以提高其整體質量。正向工程過程應用軟件工程的原理、概念、技術和方法重新開發某個現有的應用系統。具有原系統的所有功能，并加入了