第十章軟件維護

第十章軟件維護軟件工程課件第十章軟件維護10.1軟件維護的概念10.2軟件維護的活動10.3程序修改的步驟及修改的副作用10.4面向對象軟件的維護10.5軟件可維護性10.6提高可維護性的方法10.7遺留系統(tǒng)的再工程10.1軟件維護的概念在軟件運行／維護階段對軟件產品進行的修改就是所謂的維護。維護的類型有三種：改正性維護適應性維護完善性維護此外，為提高軟件產品的可維護性，還需要進行預防性維護。改正性維護在軟件交付使用后，因開發(fā)時測試的不徹底、不完全，必然會有部分隱藏的錯誤遺留到運行階段。這些隱藏下來的錯誤在某些特定的使用環(huán)境下就會暴露出來。為了識別和糾正軟件錯誤、改正軟件性能上的缺陷、排除實施中的誤使用，應當進行的診斷和改正錯誤的過程就叫做改正性維護。2.適應性維護在使用過程中，外部環(huán)境（新的硬、軟件配置）數(shù)據(jù)環(huán)境（數(shù)據(jù)庫、數(shù)據(jù)格式、數(shù)據(jù)輸入/輸出方式、數(shù)據(jù)存儲介質）可能發(fā)生變化。為使軟件適應這種變化，而去修改軟件的過程就叫做適應性維護。3.完善性維護在軟件的使用過程中，用戶往往會對軟件提出新的功能與性能要求。為了滿足這些要求，需要修改或再開發(fā)軟件，以擴充軟件功能、增強軟件性能、改進加工效率、提高軟件的可維護性。這種情況下進行的維護活動叫做完善性維護。4.預防性維護預防性維護是為了防止錯誤的功能；提高軟件的可維護性、可靠性等，為以后進一步改進軟件打下良好基礎。預防性維護定義為：采用先進的軟件工程方法對需要維護的軟件或軟件中的某一部分（重新）進行設計、編制和測試。實踐表明，在幾種維護活動中，完善性維護所占的比重最大。即大部分維護工作是改變和加強軟件，而不是糾錯。完善性維護不一定是救火式的緊急維修，而可以是有計劃、有預謀的一種再開發(fā)活動。事實證明，來自用戶的要求擴充、加強軟件功能、性能的維護活動約占整個維護工作的50％。因此，在整個軟件維護階段所花費的全部工作量中，完善性維護占了幾乎一半的工作量。

維護在軟件生

存期所占比例維護工作量70%開發(fā)工作量30%適應性維護25%改正性維護20%完善性維護50%其他維護5%三類維護占總維護比例影響維護工作量的因素在軟件的維護過程中，需要花費大量的工作量，從而直接影響了軟件維護的成本。應當考慮有哪些因素影響軟件維護的工作量，相應應該采取什么維護策略，才能有效地維護軟件并控制維護的成本。系統(tǒng)大小 系統(tǒng)越大，理解掌握越困難。系統(tǒng)越大，執(zhí)行功能越復雜。因而需要更多的維護工作量。系統(tǒng)年齡老系統(tǒng)由于不斷修改，結構越來越亂；維護人員經(jīng)常更換，程序變得越來越難于理解。許多老系統(tǒng)當初并未按照軟件工程要求進行開發(fā)，因而沒有文檔，或文檔太少。在長期的維護過程中文檔在許多地方與程序實現(xiàn)變得不一致，在維護時會遇到很大困難。程序設計語言：使用強功能的程序設計語言可以控制程序的規(guī)模。語言功能越強，生成程序的模塊化和結構化程度越高，所需指令數(shù)就越少，程序的可讀性越好。數(shù)據(jù)庫技術的應用：使用數(shù)據(jù)庫，可以簡單而有效地管理和存儲用戶程序中的數(shù)據(jù)。先進的軟件開發(fā)技術：在軟件開發(fā)時，若使用能使軟件結構比較穩(wěn)定的分析與設計技術，及程序設計技術，如面向對象技術、復用技術等，可減少大量的工作量。其它：應用的類型數(shù)學模型任務的難度開關與標記、IF嵌套深度、索引或下標數(shù)等 對維護工作量都有影響。許多軟件在開發(fā)時并未考慮將來的修改，為軟件的維護帶來許多問題。維護成本有形的軟件維護成本是花費了多少錢，無形的維護成本有更大的影響。一些合理的修復或修改請求不能及時安排，使得客戶不滿意；變更的結果引入新的故障，使得軟件整體質量下降；把軟件人員抽調到維護工作中，干擾了軟件開發(fā)工作。軟件維護的代價是降低了生產率，在做老程序的維護時非常明顯。例如，開發(fā)每一行源代碼耗資25美元，維護每一行源代碼需要耗資1000美元。維護工作量包括生產性活動(如分析和評價、設計修改和實現(xiàn))和“輪轉”活動(如力圖理解代碼在做什么、試圖判明數(shù)據(jù)結構、接口特性、性能界限等)。維護工作量的模型M是維護中消耗的總工作量p是上面描述的生產性工作量K是一個經(jīng)驗常數(shù)c是因缺乏好的設計和文檔而導致復雜性的度量d是對軟件熟悉程度的度量。模型指明，如果使用了不好的軟件開發(fā)方法，原來參加開發(fā)的人員或小組不能參加維護，則工作量（及成本）將按指數(shù)級增加。10.2軟件維護過程

為了有效地進行軟件維護，應事先就開始做組織工作。首先建立維護的機構；申明提出維護申請報告的過程及評價的過程；為每一個維護申請規(guī)定標準的處理步驟；建立維護活動的登記制度以及規(guī)定評價和評審的標準。1.維護機構除了較大的軟件開發(fā)公司外，通常在軟件維護工作方面，并不保持一個正式的組織機構。雖然不要求建立一個正式的維護機構，但是在開發(fā)部門確立一個非正式的維護機構則是非常必要的。修改負責人維護人員維護管理員系統(tǒng)監(jiān)督員配置管理員維護申請軟件維護組織維護申請?zhí)峤唤o維護管理員，他把申請交給某個系統(tǒng)監(jiān)督員去評價。一旦做出評價，由修改負責人確定如何進行修改。在修改程序的過程中，由配置管理員嚴格把關，控制修改的范圍，對軟件配置進行審計。在維護之前，就把責任明確下來，可以減少維護過程中的混亂。2.軟件維護申請報告維護申請報告或稱軟件問題報告，由申請維護的用戶填寫。用戶必須完整地說明產生錯誤的情況，包括輸入數(shù)據(jù)、錯誤清單以及其它有關材料。如果申請的是適應性維護或完善性維護，用戶必須提出一份修改說明書，列出所有希望的修改。維護申請報告將由維護管理員和系統(tǒng)監(jiān)督員來研究處理。他們應相應地做出軟件修改報告，指明：所需修改變動的性質；申請修改的優(yōu)先級；為滿足某個維護申請報告，所需的工作量；預計修改后的狀況軟件修改報告應提交修改負責人，經(jīng)批準后才能開始進一步安排維護工作。軟件工程243.維護過程模型此模型是一種軟件維護的臨時定制方法，是一種“救火式”的方法。一旦問題出現(xiàn)，盡可能迅速解決。應用此模型，不對長期效應（如對代碼的副作用）進行分析就實施修改，即使有分析也不記入文檔。這種模型是歷史發(fā)展的結果，現(xiàn)在還在用。(1)快速修改模型軟件工程25快速修改模型如果系統(tǒng)是一個人開發(fā)和維護的，他對系統(tǒng)有足夠的理解，有能力在沒有詳細文檔的情況下管理系統(tǒng)，有能力就如何實現(xiàn)變更做出本能的判斷，維護工作能夠快速、經(jīng)濟地完成?？蛻舨辉敢鉃樾薷囊粋€錯誤，等待軟件機構完成仔細和耗時的風險分析程序。發(fā)現(xiàn)問題改正錯誤(2)Boehm模型Boehm把維護過程表示為閉合環(huán)路。批準變更軟件新版本結果變更建議管理層決策使用軟件實現(xiàn)變更評估在此模型中，經(jīng)濟決策是很多過程背后的主要推動力量。維護管理人的任務是在追求維護目標和實施維護環(huán)境中的約束之間尋找平衡點。軟件工程27(3)面向復用的模型面向復用的模型將維護看作是一組復用現(xiàn)有程序構件的活動。主要有4個步驟：標識可供復用的老系統(tǒng)部件；理解這些系統(tǒng)部件；修改這些系統(tǒng)部件，以適應新的需求；將修改后的系統(tǒng)部件集成到新系統(tǒng)中。對于完整的復用模型，起始點可以是生存周期的任意階段，即需求、設計、編碼和測試等，不像快速修改模型，起始點只是編碼。需求分析設計源代碼測試需求分析設計源代碼測試構件庫老系統(tǒng)新系統(tǒng)面向復用的Basili模型軟件維護工作流程用戶維護人員確定變更要求判別維護類型評價優(yōu)先次序把安排好的維護工作量列入計劃維護要求安排改正性維護把改正錯誤列入計劃開始問題分析維護實施復審評價錯誤嚴重程度嚴重(救火)人員安排改正性不嚴重完善性適應性低高開始問題分析人員安排修改過的軟件通過并交付使用的軟件理解程序分析原設計安排計劃修改程序測試程序盡管維護申請的類型不同，但都要進行同樣的技術工作。修改軟件需求說明修改軟件設計設計評審對源程序做必要的修改單元測試集成測試（回歸測試）系統(tǒng)測試軟件配置評審等。在每次軟件維護任務完成后進行情況評審，對以下問題做一總結：在目前情況下，設計、編碼、測試中的哪一方面可以改進?哪些維護資源應該有但沒有?工作中主要的或次要的障礙是什么?從維護申請的類型來看是否應當有預防性維護?情況評審對將來的維護工作如何進行會產生重要的影響。4.維護評價評價維護活動比較困難，因為缺乏可靠的數(shù)據(jù)。如果維護的檔案記錄做得比較好，可以得出一些維護績效方面的度量值。每次程序運行時的平均出錯次數(shù)；花費在每類維護上的總“人時”數(shù)；每個程序、每種語言、每種維護類型的程序平均修改次數(shù)；因為維護，增加或刪除每個源程序語句所花費的平均“人時”數(shù)；用于每種語言的平均“人時”數(shù)；維護申請報告的平均處理時間；各類維護申請的百分比。據(jù)此可對開發(fā)技術、語言選擇、維護工作計劃、資源分配、以及其它許多方面做出判定。10.3程序修改的步驟

及修改的副作用在軟件維護時必然會對源程序進行修改。通常對源程序的修改不能無計劃地倉促上陣，為了正確、有效地修改，需要經(jīng)歷以下三個步驟。分析和理解程序修改程序重新驗證程序1.分析和理解程序經(jīng)過分析，全面、準確、迅速地理解程序是決定維護成敗和質量好壞的關鍵。在這方面，軟件的可理解性和文檔的質量非常重要。理解程序的功能和目標；掌握程序的結構信息,即從程序中細分出若干結構成分。如程序系統(tǒng)結構、控制結構、數(shù)據(jù)結構和輸入／輸出結構等；了解數(shù)據(jù)流信息，即涉及到的數(shù)據(jù)來源何處，在哪里被使用；

了解控制流信息，即執(zhí)行每條路徑的結果；理解程序的操作（使用）要求；為了容易地理解程序，要求自頂向下地理解現(xiàn)有源程序的程序結構和數(shù)據(jù)結構，為此可采用如下幾種方法：分析程序結構圖搜集所有存儲該程序的文件，閱讀這些文件，記下它們包含的過程名，建立包括這些過程名和文件名的清單；分析各個過程的源代碼，建立一個直接調用矩陣D或調用樹。若過程i調用過程j，則D[i][j]＝1，否則D[i][j]＝0。建立過程的間接調用矩陣I，即直接調用矩陣D的傳遞閉包

I＝D1∪D2∪D3∪…∪Dn

其中，n是所包含的過程總數(shù).分析各過程的接口，估計更改復雜性。數(shù)據(jù)跟蹤建立各層次程序級上的接口圖,展示各模塊或過程的調用方式和接口參數(shù)；利用數(shù)據(jù)流分析方法，對過程內部的一些變量進行跟蹤。可獲得有關數(shù)據(jù)在過程間如何傳遞，在過程內如何處理等信息。對于判斷問題原因特別有用。在跟蹤的過程中可在源程序中間插入自己的注釋。

(3)控制跟蹤控制流跟蹤可采用符號執(zhí)行或實際動態(tài)跟蹤的方法，了解數(shù)據(jù)如何從一個輸入源到達輸出點的。充分閱讀和使用源程序清單和文檔，分析現(xiàn)有文檔的合理性。充分使用由編譯程序或匯編程序提供的交叉引用表、符號表、以及其它有用的信息。如有可能，積極參加開發(fā)工作。軟件工程402.修改程序對程序的修改，必須事先做出計劃，有預謀地、周密有效地實施修改。設計程序的修改計劃制定程序的修改計劃要考慮人員和資源的安排。小的修改可以不需要詳細的計劃，而對于需要耗時數(shù)月的修改，就需要計劃立案。在編寫有關問題解決的方案時，必須充分描述修改作業(yè)的規(guī)格說明。包括：規(guī)格說明信息：數(shù)據(jù)修改、處理修改、作業(yè)控制語言修改、系統(tǒng)之間接口的修改等；維護資源：新程序版本、測試數(shù)據(jù)、所需軟件、計算機時間等；人員；支持：紙面、計算機媒體等。通常，可采用自頂向下的方法，在理解程序的基礎上，研究程序的各個模塊、模塊的接口、及數(shù)據(jù)庫，從全局的觀點，提出修改計劃。依次把要修改的以及受修改影響的模塊和數(shù)據(jù)結構分離出來。為此，要求識別受修改影響的數(shù)據(jù)；識別使用這些數(shù)據(jù)的程序模塊；對于這些程序模塊，按是產生數(shù)據(jù)、修改數(shù)據(jù)、還是刪除數(shù)據(jù)進行分類；識別這些數(shù)據(jù)的外部控制信息;識別編輯和檢查這些數(shù)據(jù)的地方；隔離要修改的部分；詳細地分析要修改的、以及那些受變更影響的模塊和數(shù)據(jù)結構的內部細節(jié)，設計修改計劃，標明新邏輯及要改動的現(xiàn)有邏輯。向用戶提供回避措施。用戶的某些業(yè)務因軟件中發(fā)生問題而中斷，為不讓系統(tǒng)長時間停止運行，需把問題局部化，在可能的范圍內繼續(xù)開展業(yè)務。 可以采取的措施有： ①查找問題原因，可能情況有：軟件工程44意外停機安裝的期限到期系統(tǒng)運行中發(fā)現(xiàn)錯誤②如果弄清了問題的原因,可通過臨時修改或改變運行控制以回避在系統(tǒng)運行時產生的問題。修改代碼，以適應變化在修改時，要求：正確、有效地編寫修改代碼；要謹慎地修改程序,盡量保持程序的風格及格式,要在程序清單上注明改動的指令；不要刪除程序語句，除非完全肯定它是無用的；不要試圖共用程序中已有的臨時變量或工作區(qū)，應設置自己的變量；插入錯誤檢測語句；在修改過程中做好修改的詳細記錄，消除變更中任何有害的副作用（波動效應）；

修改程序的副作用 所謂副作用是指因修改軟件而造成的錯誤或其它不希望發(fā)生的情況。副作用有三種：修改代碼的副作用、修改數(shù)據(jù)的副作用、文檔的副作用。修改代碼的副作用 在修改源代碼時，都可能引入錯誤。刪除或修改一個子程序刪除或修改一個標識符改變程序代碼的時序關系改變占用存儲的大小改變邏輯運算符修改文件的打開或關閉改進程序的執(zhí)行效率把設計上的改變翻譯成代碼的改變修改數(shù)據(jù)的副作用在修改數(shù)據(jù)結構時可能造成軟件設計與數(shù)據(jù)結構不匹配，因而導致軟件出錯。數(shù)據(jù)副作用就是修改軟件信息結構導致的結果。容易導致設計與數(shù)據(jù)不相容的錯誤有：重新定義記錄或文件的格式增減一個數(shù)組或高層數(shù)據(jù)結構的大小修改全局或公共數(shù)據(jù)重新初始化控制標志或指針重新排列輸入／輸出或子程序的參數(shù)數(shù)據(jù)副作用可以通過交叉引用表加以控制。把數(shù)據(jù)元素、記錄、文件和其它結構聯(lián)系起來。文檔的副作用對數(shù)據(jù)流、軟件結構、模塊邏輯或任何其它有關特性進行修改時，必須對相關技術文檔進行相應修改。否則會導致文檔與程序功能不匹配，缺省條件改變，新錯誤信息不正確等錯誤。使得軟件文檔不能反映軟件的當前狀態(tài)。對于用戶來說，軟件事實上就是文檔。如果對可執(zhí)行軟件的修改不反映在文檔里，就會產生文檔的副作用。對交互輸入的順序或格式進行修改，如果沒有正確地記入文檔中，就可能引起重大的問題。過時的文檔內容、索引和文本可能造成沖突，引起用戶失敗和不滿。因此，必須在軟件交付之前對整個軟件配置進行評審，以減少文檔的副作用。為了控制因修改而引起的副作用，要做到：按模塊把修改分組；自頂向下地安排被修改模塊的順序；每次修改一個模塊；對于每個修改了的模塊，在安排修