第十章軟件維護

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

維護在軟件生

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

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

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

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

I＝D1∪D2∪D3∪…∪Dn

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

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

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