軟件維護課件

1

第八章

軟件維護

普通人輕視軟件維護工作，

會失掉極其寶貴的機會；

維護人員輕視軟件維護工作，

會失掉本應(yīng)精彩的人生；

老板輕視軟件維護工作，

會丟掉大片本來屬于自己的市場……

1第八章

軟件維護

普通人輕視軟件維護工作2第八章軟件維護8.1軟件維護的定義軟件維護

----就是在軟件已經(jīng)交付使用之后，為保證軟件在相當長的時期能夠正常運作所進行的軟件活動。

維護的類型有四種：

改正性維護適應(yīng)性維護擴充與完善性維護預(yù)防性維護2第八章軟件維護8.1軟件維護的定義3改正性維護---CorrectiveMaintenance在軟件交付使用后，因開發(fā)時測試的不徹底、不完全，必然會有部分隱藏的錯誤遺留到運行階段。這些隱藏下來的錯誤在某些特定的使用環(huán)境下就會暴露出來。為了識別和糾正軟件錯誤、改正軟件性能上的缺陷、排除實施中的誤使用，所進行的診斷和改正錯誤的過程就叫做改正性維護。3改正性維護---CorrectiveMaint4適應(yīng)性維護

---AdaptiveMaintenance

在使用過程中，外部環(huán)境（新的硬、軟件配置）

數(shù)據(jù)環(huán)境（數(shù)據(jù)庫、數(shù)據(jù)格式、數(shù)據(jù)輸入/輸出方式、數(shù)據(jù)存儲介質(zhì)）可能發(fā)生變化。為使軟件適應(yīng)這種變化，而去修改軟件的過程就叫做適應(yīng)性維護。

4適應(yīng)性維護---AdaptiveMaintena5擴充與完善性維護---PerfectiveMaintenance

在軟件的使用過程中，用戶往往會對軟件提出新的功能與性能要求。為了滿足這些要求，需要修改或再開發(fā)軟件，以擴充軟件功能、增強軟件性能、改進加工效率、提高軟件的可維護性。這種情況下進行的維護活動叫做擴充與完善性維護。5擴充與完善性維護---PerfectiveMaint6預(yù)防性維護---PreventiveMaintenance預(yù)防性維護是為了提高軟件的可維護性、可靠性等，為以后進一步改進軟件打下良好基礎(chǔ)。預(yù)防性維護定義為：采用先進的軟件工程方法對需要維護的軟件或軟件中的某一部分（重新）進行設(shè)計、編制和測試。6預(yù)防性維護---PreventiveMaintena7各種維護所占比例:其它維護4%適應(yīng)性維護18%～25%改正性維護

17%～

21%擴充與完善性維護50%～60%7各種維護所占比例:其它維護4%適應(yīng)性維護改正性維護擴充88.2軟件維護的特點

--影響維護工作量的因素系統(tǒng)大小：系統(tǒng)越大，理解掌握起來越困難。系統(tǒng)越大，所執(zhí)行功能越復(fù)雜。因而需要更多的維護工作量。程序設(shè)計語言：使用強功能的程序設(shè)計語言可以控制程序的規(guī)模。語言的功能越強，生成程序的模塊化和結(jié)構(gòu)化程度越高，所需的指令數(shù)就越少，程序的可讀性越好。88.2軟件維護的特點--影響維護工作量的因素9系統(tǒng)年齡：老系統(tǒng)隨著不斷的修改，結(jié)構(gòu)越來越亂；維護人員經(jīng)常更換，程序又變得越來越難于理解許多老系統(tǒng)在當初并未按照軟件工程的要求進行開發(fā)，因而沒有文檔，或文檔太少。在長期的維護過程中文檔在許多地方與程序?qū)崿F(xiàn)變得不一致，在維護時就會遇到很大困難。數(shù)據(jù)庫技術(shù)的應(yīng)用：使用數(shù)據(jù)庫，可以簡單而有效地管理和存儲用戶程序中的數(shù)據(jù)，還可以減少生成用戶報表應(yīng)用軟件的維護工作量。9系統(tǒng)年齡：10先進的軟件開發(fā)技術(shù)：在軟件開發(fā)時，若使用能使軟件結(jié)構(gòu)比較穩(wěn)定的分析與設(shè)計技術(shù)，及程序設(shè)計技術(shù)，如面向?qū)ο蠹夹g(shù)、復(fù)用技術(shù)等，可減少大量的工作量。其它：

應(yīng)用的類型數(shù)學模型任務(wù)的難度開關(guān)與標記、IF嵌套深度、索引或下標數(shù)等 對維護工作量都有影響。許多軟件在開發(fā)時并未考慮將來的修改，為軟件的維護帶來許多問題。10先進的軟件開發(fā)技術(shù)：在軟件開發(fā)時，若使用能使軟件結(jié)構(gòu)比較11維護成本有形的軟件維護成本是花費了多少錢，無形的維護成本有更大的影響?？捎玫馁Y源必須供維護任務(wù)使用,以致耽誤甚至喪失開發(fā)的良機;

一些合理的修復(fù)或修改請求不能及時安排，使得客戶不滿意；變更的結(jié)果引入新的故障，使得軟件整體質(zhì)量下降；把軟件人員抽調(diào)到維護工作中，干擾了軟件開發(fā)工作。11維護成本有形的軟件維護成本是花費了多少錢，無形的維護成本12維護工作量的模型M

是維護中消耗的總工作量P

是生產(chǎn)性工作量K

是一個經(jīng)驗常數(shù)c

是因缺乏好的設(shè)計和文檔而導致復(fù)雜性的度量d是維護人員對軟件熟悉程度的度量模型指明，如果使用了不好的軟件開發(fā)方法（未按軟件工程要求做），原來參加開發(fā)的人員或小組不能參加維護，則工作量（及成本）將按指數(shù)級增加。12維護工作量的模型M是維護中消耗的總工作量138.2.3維護中的典型問題(1)

難以跟蹤軟件版本的進化過程,軟件的變化未在文檔中反映出來.(2)難以跟蹤軟件的創(chuàng)建過程.(3)難以讀懂他人程序.(4)無文檔或不全.(5)軟件人員流動性大.(6)設(shè)計時未考慮修改需要,修改困難.維護工作無吸引力,缺乏成就感.采用軟件工程方法至少可部分地解決與維護有關(guān)的每一個問題。138.2.3維護中的典型問題(1)難以跟蹤軟件148.3軟件維護過程維護過程本質(zhì)上是修改和壓縮了的軟件定義和開發(fā)過程，而且事實上遠在提出一項維護要求之前，與軟件維護有關(guān)的工作已經(jīng)開始了。為了有效地進行軟件維護，應(yīng)事先就開始做組織工作。

首先建立維護的機構(gòu)

申明提出維護申請報告的過程及評價的過程

為每一個維護申請規(guī)定標準的處理步驟

建立維護活動的記錄保管，并規(guī)定復(fù)審的標準148.3軟件維護過程維護過程本質(zhì)上是修改和壓縮了的軟件151、維護機構(gòu)除了較大的軟件開發(fā)公司外，通常在軟件維護工作方面，并不保持一個正式的組織機構(gòu)。雖然不要求建立一個正式的維護機構(gòu)，但是在開發(fā)部門確立一個非正式的維護機構(gòu)則是非常必要的。151、維護機構(gòu)除了較大的軟件開發(fā)公司外，通常在軟件維護工作16每個維護要求都通過維護管理員轉(zhuǎn)交給相應(yīng)的系統(tǒng)管理員去評價（系統(tǒng)管理員是被指定去熟悉一小部分產(chǎn)品程序的技術(shù)人員）。系統(tǒng)管理員對維護任務(wù)做出評價之后，由變化授權(quán)人決定應(yīng)該進行的活動。16每個維護要求都通過維護管理員轉(zhuǎn)交給相應(yīng)的系統(tǒng)管理員去評價172.維護報告應(yīng)該用標準化的格式表達所有軟件維護申請（要求）。維護申請報告或稱軟件問題報告，由申請維護的用戶填寫。用戶必須完整地說明產(chǎn)生錯誤的情況，包括輸入數(shù)據(jù)、錯誤清單以及其它有關(guān)材料。如果申請的是適應(yīng)性維護或完善性維護，用戶必須提出一份修改說明書，列出所有希望的修改。172.維護報告18維護申請報告將由維護管理員和系統(tǒng)管理員來研究處理。他們應(yīng)相應(yīng)地做出軟件修改報告，指明：所需修改變動的性質(zhì)；申請修改的優(yōu)先級；為滿足某個維護申請報告，所需的工作量預(yù)計修改后的狀況.軟件修改報告應(yīng)提交給變化授權(quán)人（修改負責人），經(jīng)批準后才能開始進一步安排維護工作。18維護申請報告將由維護管理員和系統(tǒng)管理員來研究處理。193.維護的事件流193.維護的事件流20盡管維護申請的類型不同，但都要進行同樣的技術(shù)工作。修改軟件需求說明修改軟件設(shè)計設(shè)計評審對源程序做必要的修改單元測試集成測試(回歸測試)

確認測試軟件配置評審等。20盡管維護申請的類型不同，但都要進行同樣的技術(shù)工作。21

在每次軟件維護任務(wù)完成后進行情況評審，對以下問題做一總結(jié)：

(1)

在目前情況下，設(shè)計、編碼、測試中的哪一方面可以改進?

(2)

哪些維護資源應(yīng)該有但沒有?

(3)

工作中主要的或次要的障礙是什么?

(4)

從維護申請的類型來看是否應(yīng)當有預(yù)防性維護?

情況評審對將來的維護工作如何進行會產(chǎn)生重要的影響。21在每次軟件維護任務(wù)完成后進行情況評審，對以下問題做一224、維護檔案記錄①程序標識；②源語句數(shù)；③機器指令條數(shù)；④使用的程序設(shè)計語言；⑤程序安裝的日期；⑥自從安裝以來程序運行的次數(shù)；⑦自從安裝以來程序失效的次數(shù)；⑧程序變動的層次和標識；⑨因程序變動而增加的源語句數(shù)；⑽因程序變動而刪除的源語句數(shù)；⑾每個改動耗費的人時數(shù)；⑿程序改動的日期；⒀軟件工程師的名字；⒁維護要求表的標識；⒂維護類型；⒃維護開始和完成的日期；⒄累計用于維護的人時數(shù)；⒅與完成的維護相聯(lián)系的純效益。224、維護檔案記錄①程序標識；②源語句數(shù)；③機器指令條235、維護評價評價維護活動比較困難，因為缺乏可靠的數(shù)據(jù)。如果維護的檔案記錄做得比較好，可以得出一些維護“性能”方面的度量值。

(1)每次程序運行平均失效的次數(shù)；(2)用于每一類維護活動的總?cè)藭r數(shù)；(3)平均每個程序、每種語言、每種維護類型所做的程序變動數(shù)；(4)維護過程中增加或刪除一個源語句平均花費的人時數(shù)；(5)維護每種語言平均花費的人時數(shù)；(6)一張維護要求表的平均周轉(zhuǎn)時間；(7)不同維護類型所占的百分比。根據(jù)對維護工作定量度量的結(jié)果，可以做出關(guān)于開發(fā)技術(shù)、語言選擇、維護工作量規(guī)劃、資源分配及其他許多方面的決定，而且可以利用這樣的數(shù)據(jù)去分析評價維護任務(wù)。235、維護評價評價維護活動比較困難，因為缺乏可靠的數(shù)據(jù)。24程序修改的步驟及修改的副作用(自學)在軟件維護時，必然會對源程序進行修改。通常對源程序的修改不能無計劃地倉促上陣，為了正確、有效地修改,需要經(jīng)歷以下三個步驟。

分析和理解程序

修改程序

重新驗證程序24程序修改的步驟及修改的副作用(自學)在軟件維護時，必然會25分析和理解程序經(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)等；25分析和理解程序經(jīng)過分析，全面、準確、迅速地理解程序是決定26

了解數(shù)據(jù)流信息，即涉及到的數(shù)據(jù)來源何處，在哪里被使用；了解控制流信息，即執(zhí)行每條路徑的結(jié)果；理解程序的操作(使用)要求；為了容易地理解程序，要求自頂向下地理解現(xiàn)有源程序的程序結(jié)構(gòu)和數(shù)據(jù)結(jié)構(gòu)，為此可采用如下幾種方法：26

了解數(shù)據(jù)流信息，即涉及到的數(shù)據(jù)來源何處，在哪里被使用271.分析程序結(jié)構(gòu)圖

(1)搜集所有存儲該程序的文件，閱讀這些文件，記下它們包含的過程名，建立一個包括這些過程名和文件名的清單；

(2)分析各個過程的源代碼，建立一個直接調(diào)用矩陣D或調(diào)用樹。若過程i調(diào)用過程j，則D[i][j]＝1，否則D[i][j]＝0。271.分析程序結(jié)構(gòu)圖

(1)搜集所有存儲該程序的文件，28

(3)建立過程的間接調(diào)用矩陣I，即直接調(diào)用矩陣D的傳遞閉包

I＝D1∪D2∪D3∪…∪Dn

其中，n是所包含的過程總數(shù).

例如，過程i調(diào)用j，j調(diào)用k， 則D[i][j]＝1，D[j][k]＝1，

I[i][k]＝1。

(4)分析各個過程的接口，估計更改的復(fù)雜性。

28 (3)建立過程的間接調(diào)用矩陣I，即直接調(diào)用矩陣D的傳292.數(shù)據(jù)跟蹤

(1)建立各層次的程序級上的接口圖，展示各模塊或過程的調(diào)用方式和接口參數(shù)；

(2)利用數(shù)據(jù)流分析方法，對過程內(nèi)部的一些變量進行跟蹤。可獲得有關(guān)數(shù)據(jù)在過程間如何傳遞，在過程內(nèi)如何處理等信息。對于判斷問題原因特別有用。在跟蹤的過程中可在源程序中間插入自己的注釋。292.數(shù)據(jù)跟蹤

(1)建立各層次的程序級上的接口圖，展303.控制跟蹤 控制流跟蹤可采用符號執(zhí)行或?qū)嶋H動態(tài)跟蹤的方法，了解數(shù)據(jù)如何從一個輸入源到達輸出點的。4.充分閱讀和使用源程序清單和文檔，分析現(xiàn)有文檔的合理性。5.充分使用由編譯程序或匯編程序提供的交叉引用表、符號表、以及其它有用的信息。6.

如有可能，積極參加開發(fā)工作。303.控制跟蹤31修改程序?qū)Τ绦虻男薷?，必須事先做出計劃，有預(yù)謀地、周密有效地實施修改。1.設(shè)計程序的修改計劃 程序的修改計劃要考慮人員和資源的安排。小的修改可以不需要詳細的計劃，而對于需要耗時數(shù)月的修改，就需要計劃立案。31修改程序?qū)Τ绦虻男薷?，必須事先做出計劃，有預(yù)謀地、周密有32 在編寫有關(guān)問題解決的方案時，必須充分描述修改作業(yè)的規(guī)格說明。

規(guī)格說明信息：數(shù)據(jù)修改、處理修改、作業(yè)控制語言修改、系統(tǒng)之間接口的修改等；

維護資源：新程序版本、測試數(shù)據(jù)、所需軟件、計算機時間等；

人員；

支持：紙面、計算機媒體等。32 在編寫有關(guān)問題解決的方案時，必須充分描述修改作業(yè)的規(guī)格33 通常，可采用自頂向下的方法，在理解程序的基礎(chǔ)上，

(1)

研究程序的各個模塊、模塊的接口及數(shù)據(jù)庫，從全局的觀點，提出修改計劃。

(2)

依次地把要修改的以及那些受修改影響的模塊和數(shù)據(jù)結(jié)構(gòu)分離出來。為此，要

識別受修改影響的數(shù)據(jù)；

識別使用這些數(shù)據(jù)的程序模塊；33 通常，可采用自頂向下的方法，在理解程序的基礎(chǔ)上，

(134

對于上面程序模塊，按是產(chǎn)生數(shù)據(jù)、修改數(shù)據(jù)、還是刪除數(shù)據(jù)進行分類；

識別對這些數(shù)據(jù)元素的外部控制信息；

識別編輯和檢查這些數(shù)據(jù)元素的地方；

隔離要修改的部分；34 對于上面程序模塊，按是產(chǎn)生數(shù)據(jù)、修改數(shù)據(jù)、還是刪35(3)

詳細地分析要修改的、以及那些受變更影響的模塊和數(shù)據(jù)結(jié)構(gòu)的內(nèi)部細節(jié)，設(shè)計修改計劃，標明新邏輯及要改動的現(xiàn)有邏輯。(4)

向用戶提供回避措施。用戶的某些業(yè)務(wù)因軟件中發(fā)生問題而中斷，為不讓系統(tǒng)長時間停止運行，需把問題局部化，在可能的范圍內(nèi)繼續(xù)開展業(yè)務(wù)。 可以采取的措施有：35(3)詳細地分析要修改的、以及那些受變更影響的模塊和數(shù)36①查找問題原因，可能情況有：

意外停機

安裝的期限到期

系統(tǒng)運行中發(fā)現(xiàn)錯誤②如果弄清了問題的原因，可通過臨時修改或改變運行控制以回避在系統(tǒng)運行時產(chǎn)生的問題。36①查找問題原因，可能情況有：372.修改代碼，以適應(yīng)變化

在修改時，要求：

(1)

正確、有效地編寫修改代碼；

(2)

要謹慎地修改程序，盡量保持程序的風格及格式，要在程序清單上注明改動的指令；

(3)

不要刪除程序語句，除非完全肯定它是無用的；

(4)

不要試圖共用程序中已有的臨時變量或工作區(qū)，為了避免沖突或混淆用途，應(yīng)設(shè)置自己的變量；

372.修改代碼，以適應(yīng)變化

在修改時，要求：

38

(5)

插入錯誤檢測語句；

(6)

在修改過程中做好修改的詳細記錄，消除變更中任何有害的副作用（波動效應(yīng)）；3.修改程序的副作用

所謂副作用是指因修改軟件而造成的錯誤或其它不希望發(fā)生的情況。副作用有三種：修改代碼的副作用、修改數(shù)據(jù)的副作用、文檔的副作用。38 (5)插入錯誤檢測語句；

(6)在修改過程中做好修39

在修改源代碼時，都可能引入錯誤。例如，刪除或修改一個子程序、刪除或修改一個標號、刪除或修改一個標識符、改變程序代碼的時序關(guān)系、改變占用存儲的大小、改變邏輯運算符、修改文件的打開或關(guān)閉、改進程序的執(zhí)行效率，以及把設(shè)計上的改變翻譯成代碼的改變時，都容易引入錯誤。(1)修改代碼的副作用39

在修改源代碼時，都可能引入錯誤。例如，刪除或修改一個子40(2)修改數(shù)據(jù)的副作用在修改數(shù)據(jù)結(jié)構(gòu)時，有可能造成軟件設(shè)計與數(shù)據(jù)結(jié)構(gòu)不匹配，因而導致軟件出錯。數(shù)據(jù)副作用就是修改軟件信息結(jié)構(gòu)導致的結(jié)果。容易導致設(shè)計與數(shù)據(jù)不相容的錯誤可以有：

重新定義局部的或全局的常量40(2)修改數(shù)據(jù)的副作用在修改數(shù)據(jù)結(jié)構(gòu)時，有可能造成軟件41

重新定義記錄或文件的格式增大或減小一個數(shù)組或高層數(shù)據(jù)結(jié)構(gòu)的大小修改全局或公共數(shù)據(jù)重新初始化控制標志或指針重新排列輸入／輸出或子程序的參數(shù)數(shù)據(jù)副作用可以通過交叉引用表加以控制。把數(shù)據(jù)元素、記錄、文件和其它結(jié)構(gòu)聯(lián)系起來。41重新定義記錄或文件的格式42(3)文檔的副作用對數(shù)據(jù)流、軟件結(jié)構(gòu)、模塊邏輯或任何其它有關(guān)特性進行修改時，必須對相關(guān)技術(shù)文檔進行相應(yīng)修改。否則會導致文檔與程序功能不匹配，缺省條件改變，新錯誤信息不正確等錯誤。使得軟件文檔不能反映軟件的當前狀態(tài)。對于用戶來說，軟件事實上就是文檔。42(3)文檔的副作用對數(shù)據(jù)流、軟件結(jié)構(gòu)、模塊邏輯或任何43如果對可執(zhí)行軟件的修改不反映在文檔里，就會產(chǎn)生文檔的副作用。對交互輸入的順序或格式進行修改，如果沒有正確地記入文檔中，就可能引起重大的問題。過時的文檔內(nèi)容、索引和文本可能造成沖突，引起用戶失敗和不滿。因此，必須在軟件交付之前對整個軟件配置進行評審，以減少文檔的副作用。43如果對可執(zhí)行軟件的修改不反映在文檔里，就會產(chǎn)生文檔的副作44為了控制因修改而引起的副作用，要做到：

(1)按模塊把修改分組；

(2)自頂向下地安排被修改模塊的順序；

(3)每次修改一個模塊；

(4)對于每個修改了的模塊，在安排修改下一個模塊之前，要確定這個修改的副作用。可以使用交叉引用表、存儲映象表、執(zhí)行流程跟蹤等。44為了控制因修改而引起的副作用，要做到：

(1)按模塊把45重新驗證程序在將修改后的程序提交用戶之前，需要進行充分的確認和測試，以保證整個修改后程序的正確性。靜態(tài)確認

修改軟件，伴隨著引起新的錯誤的危險。為了能夠做出正確的判斷，驗證修改后的程序至少需要兩個人參加。要檢查：

45重新驗證程序在將修改后的程序提交用戶之前，需要進行充分的46

(1)

修改是否涉及到規(guī)格說明?修改結(jié)果是否符合規(guī)格說明?有沒有歪曲規(guī)格說明?

(2)

程序的修改是否足以修正軟件中的問題?源程序代碼有無邏輯錯誤?修改時有無修補失誤?

(3)

修改部分對其它部分有無不良影響(副作用)?

對軟件進行修改，常常會引發(fā)別的問題，有必要檢查修改的影響范圍。46 (1)修改是否涉及到規(guī)格說明?修改結(jié)果是否符合規(guī)47計算機確認

在進行了以上確認的基礎(chǔ)上，用計算機對修改程序進行確認測試：

(1)確認測試順序：先對修改部分進行測試，然后隔離修改部分，測試程序的未修改部分，最后再把它們集成起來進行測試。這種測試稱為回歸測試。

(2)

準備標準的測試用例。

(3)充分利用軟件工具幫助重新驗證過程。47計算機確認

在進行了以上確認的基礎(chǔ)上，用計算機對修改程序48

(4)在重新確認過程中，需邀請用戶參加。維護后的驗收──在交付新軟件之前，維護主管部門要檢驗：

(1)

全部文檔是否完備，并已更新；

(2)

所有測試用例和測試結(jié)果已經(jīng)正確記載；

(3)

記錄軟件配置所有副本的工作已經(jīng)完成；

(4)

維護工序和責任已經(jīng)確定。48 (4)在重新確認過程中，需邀請用戶參加。49從維護角度來看所需測試種類

(1)對修改事務(wù)的測試；

(2)對修改程序的測試；

(3)操作過程的測試；

(4)應(yīng)用系統(tǒng)運用過程的測試；

(5)系統(tǒng)各部分之間接口的測試；

(6)作業(yè)控制語言的測試；

(7)與系統(tǒng)軟件接口的測試；49從維護角度來看所需測試種類 (1)對修改事務(wù)的測試；50

(8)軟件系統(tǒng)之間接口的測試；

(9)安全性測試；

(10)后備／恢復(fù)過程的測試。50 (8)軟件系統(tǒng)之間接口的測試；518.4軟件的可維護性許多軟件的維護十分困難，原因在于這些軟件的文檔不全、質(zhì)量差、開發(fā)過程不注意采用好的方法，忽視程序設(shè)計風格等。許多維護要求并不是因為程序中出錯而提出的，而是為適應(yīng)環(huán)境變化或需求變化而提出的。為了使得軟件能夠易于維護，必須考慮使軟件具有可維護性。軟件可維護性是指糾正軟件系統(tǒng)出現(xiàn)的錯誤和缺陷，以及為滿足新的要求進行修改、擴充或壓縮的容易程度。518.4軟件的可維護性許多軟件的維護十分困難，原因在于528.4.1決定軟件可維護性的因素

1.可理解性表現(xiàn)為外來讀者理解軟件的結(jié)構(gòu)、功能、接口和內(nèi)部處理過程的難易程度。模塊化（模塊結(jié)構(gòu)良好，高內(nèi)聚，松耦合）、詳細的設(shè)計文檔、結(jié)構(gòu)化設(shè)計、程序內(nèi)部的文檔和良好的高級程序設(shè)計語言等等，都對提高軟件的可理解性有重要貢獻。2.可測試性診斷和測試的容易程度取決于軟件容易理解的程度。軟件結(jié)構(gòu)、可用的測試工具和調(diào)試工具，以及以前設(shè)計的測試過程也都是非常重要的

528.4.1決定軟件可維護性的因素1.可理解性538.4.1決定軟件可維護性的因素3.可修改性(和第五章設(shè)計原理和啟發(fā)規(guī)則直接有關(guān))4.可移植性

把程序從一種計算機環(huán)境(硬件配置和操作系統(tǒng))轉(zhuǎn)移到

另一種計算環(huán)境的難易程度.5.可重用性指同一事物不做修改或稍加改動就在不同的環(huán)境中多次

重復(fù)使用.538.4.1決定軟件可維護性的因素3.可修改性(548.4.2文檔文檔是影響軟件可維護性的決定因素。往往文檔比程序代碼更重要。軟件系統(tǒng)的文檔可以分為用戶文檔和系統(tǒng)文檔兩類。

----用戶文檔主要描述系統(tǒng)功能和使用方法，并不關(guān)心這些功能是怎樣實現(xiàn)的；

----系統(tǒng)文檔描述系統(tǒng)設(shè)計、實現(xiàn)和測試等各方面的內(nèi)容。548.4.2文檔文檔是影響軟件可維護性的決定因素。往55軟件文檔應(yīng)該滿足下述要求：(1)必須描述如何使用這個系統(tǒng)，沒有這種描述時即使是最簡單的系統(tǒng)也無法使用；(2)必須描述怎樣安裝和管理這個系統(tǒng)；(3)必須描述系統(tǒng)需求和設(shè)計；(4)必須描述系統(tǒng)的實現(xiàn)和測試，以便使系統(tǒng)成為可維護的。55軟件文檔應(yīng)該滿足下述要求：561.用戶文檔用戶文檔是用戶了解系統(tǒng)的第一步，它應(yīng)該能使用戶獲得對系統(tǒng)的準確的初步印象。文檔的結(jié)構(gòu)方式應(yīng)該使用戶能夠方便地根據(jù)需要閱讀有關(guān)的內(nèi)容。用戶文檔至少應(yīng)該包括下述5方面的內(nèi)容：(1)功能描述；(2)安裝文檔；(3)使用手冊；(4)參考手冊；(5)操作員指南(如果需要有系統(tǒng)操作員的話)。上述內(nèi)容可以分別作為獨立的文檔，也可以作為一個文檔的不同分冊，具體做法應(yīng)該由系統(tǒng)規(guī)模決定。561.用戶文檔572.系統(tǒng)文檔

----所謂系統(tǒng)文檔指從問題定義、需求說明到驗收測試計劃這樣一系列和系統(tǒng)實現(xiàn)有關(guān)的文檔。

----描述系統(tǒng)設(shè)計、實現(xiàn)和測試的文檔對于理解程序和維護程序來說是極端重要的。

----和用戶文檔類似，系統(tǒng)文檔的結(jié)構(gòu)也應(yīng)該能把讀者從對系統(tǒng)概貌的了解，引導到對系統(tǒng)每個方面每個特點的更形式化更具體的認識。572.系統(tǒng)文檔588.4.3提高可維護性的方法建立明確的軟件質(zhì)量目標和優(yōu)先級使用提高軟件質(zhì)量的技術(shù)和工具進行明確的質(zhì)量保證審查選擇可維護的程序設(shè)計語言改進程序的文檔588.4.3提高可維護性的方法建立明確的軟件質(zhì)量目標和優(yōu)598.4.4可維護性復(fù)審在軟件工程過程的每一個階段都應(yīng)該考慮并努力提高軟件的可維護性，在每個階段結(jié)束前的技術(shù)審查和管理復(fù)審中，應(yīng)該著重對可維護性進行復(fù)審。598.4.4可維護性復(fù)審在軟件工程過程的每一個階段都應(yīng)60在完成了每項維護工作之后，都應(yīng)該對軟件維護本身進行仔細認真的復(fù)審。

---維護應(yīng)該針對整個軟件配置，不應(yīng)該只修改源程序代碼。當對源程序代碼的修改沒有反映在設(shè)計文檔或用戶手冊中時，就會產(chǎn)生嚴重的后果。

---每當對數(shù)據(jù)、軟件結(jié)構(gòu)、模塊過程或任何其他有關(guān)的軟件特點做了改動時，必須立即修改相應(yīng)的技術(shù)文檔。不能準確反映軟件當前狀態(tài)的設(shè)計文檔可能比完全沒有文檔更壞。

---用戶通常根據(jù)描述軟件特點和使用方法的用戶文檔來使用、評價軟件。如果對軟件的可執(zhí)行部分的修改沒有及時反映在用戶文檔中，則必然會使用戶因為受挫折而產(chǎn)生不滿。60在完成了每項維護工作之后，都應(yīng)該對軟件維護本身進行仔細認618.5預(yù)防性維護預(yù)防性維護方法是由Miller提出來的，他把這種方法定義為：“把今天的方法學應(yīng)用到昨天的系統(tǒng)上，以支持明天的需求?！遍_發(fā)和維護者不應(yīng)等待用戶的維護申請,在條件具備時應(yīng)該主動地進行預(yù)防性維護。預(yù)防性維護對象:預(yù)計若干年內(nèi)將繼續(xù)使用的程序當今正成功使用的程序最近的將來要進行大修改和完善的程序618.5預(yù)防性維護預(yù)防性維護方法是由Miller提出來再工程是一個重構(gòu)活動（類比重建一所房子）開始重建前，首先檢查一下房子。確定它是否確實需要重建？在拆掉并重建房子前，確定其結(jié)構(gòu)是否牢固。若結(jié)構(gòu)良好，則可能是“改造”。在開始重建前，確保你已經(jīng)了解房子最初是如何建造的。（墻內(nèi)部，了解布線、管道以及內(nèi)部結(jié)構(gòu)。）如果開始重建，應(yīng)該使用最現(xiàn)代的，耐久的材料。如果決定重建，一定要采用嚴格的方式，使用現(xiàn)在及將來都將獲得高質(zhì)量的做法。8.6軟件再工程過程（SoftwareReengineering）

再工程是一個重構(gòu)活動（類比重建一所房子）8.6軟件再工638.6軟件再工程過程（SoftwareReengineering）

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

需求新需求設(shè)計設(shè)計代碼代碼正向工程逆向工程（重構(gòu)）（重構(gòu)）（重構(gòu)）64軟件再工程過程示意圖需求新需求設(shè)計設(shè)計代碼代碼正65軟件再工程過程模型所定義的6類活動1.庫存目錄分析2.文檔重構(gòu)3.逆向工程4.代碼重構(gòu)5.數(shù)據(jù)重構(gòu)6.正向工程65軟件再工程過程模型所定義的6類活動1.庫存目錄分析1.庫存目錄分析；包含每個應(yīng)用系統(tǒng)的信息，如：名稱、構(gòu)建日期、修改次數(shù)、過去18個月報告的錯誤、用戶數(shù)量、文檔質(zhì)量、預(yù)期壽命等。從中選出再工程的候選者。2.文檔重構(gòu)；（1）如果一個程序走向生命終點，不再經(jīng)歷變化，則保持現(xiàn)狀；（2）重構(gòu)只針對當前正在修改的軟件部分；（3）關(guān)鍵部分需重構(gòu)全部文檔時，工作量應(yīng)減至最小。3.逆向工程；

逆向工程是一個恢復(fù)設(shè)計結(jié)果的過程，從程序代碼中抽取數(shù)據(jù)結(jié)構(gòu)、體系結(jié)構(gòu)和處理過程的設(shè)計信息。1.庫存目錄分析；4.代碼重構(gòu)；分析源代碼，標注出與結(jié)構(gòu)化程序設(shè)計概念不符的部分，重構(gòu)它的代碼，測試重構(gòu)代碼并更新代碼。5.數(shù)據(jù)重構(gòu)；當數(shù)據(jù)結(jié)構(gòu)較差時，進行再工程。如以文件方式保存數(shù)據(jù)變?yōu)橐詳?shù)據(jù)庫方式存儲。6.正向工程。也稱革新或改造，即應(yīng)用軟件工程的原理、概念、技術(shù)和方法來重新開發(fā)現(xiàn)有系統(tǒng)。4.代碼重構(gòu)；本章小結(jié)軟件維護的4類活動（改正性、適應(yīng)性、完善性、預(yù)防性）決定軟件可維護性的基本要素（可理解、可測試、可修改、可移植和可重用性）文檔是影響軟件可維護性的決定因素軟件再工程（預(yù)防性維護）本章小結(jié)軟件維護的4類活動696970

第八章

軟件維護

普通人輕視軟件維護工作，

會失掉極其寶貴的機會；

維護人員輕視軟件維護工作，

會失掉本應(yīng)精彩的人生；

老板輕視軟件維護工作，

會丟掉大片本來屬于自己的市場……

1第八章

軟件維護

普通人輕視軟件維護工作71第八章軟件維護8.1軟件維護的定義軟件維護

----就是在軟件已經(jīng)交付使用之后，為保證軟件在相當長的時期能夠正常運作所進行的軟件活動。

維護的類型有四種：

改正性維護適應(yīng)性維護擴充與完善性維護預(yù)防性維護2第八章軟件維護8.1軟件維護的定義72改正性維護---CorrectiveMaintenance在軟件交付使用后，因開發(fā)時測試的不徹底、不完全，必然會有部分隱藏的錯誤遺留到運行階段。這些隱藏下來的錯誤在某些特定的使用環(huán)境下就會暴露出來。為了識別和糾正軟件錯誤、改正軟件性能上的缺陷、排除實施中的誤使用，所進行的診斷和改正錯誤的過程就叫做改正性維護。3改正性維護---CorrectiveMaint73適應(yīng)性維護

---AdaptiveMaintenance

在使用過程中，外部環(huán)境（新的硬、軟件配置）

數(shù)據(jù)環(huán)境（數(shù)據(jù)庫、數(shù)據(jù)格式、數(shù)據(jù)輸入/輸出方式、數(shù)據(jù)存儲介質(zhì)）可能發(fā)生變化。為使軟件適應(yīng)這種變化，而去修改軟件的過程就叫做適應(yīng)性維護。

4適應(yīng)性維護---AdaptiveMaintena74擴充與完善性維護---PerfectiveMaintenance

在軟件的使用過程中，用戶往往會對軟件提出新的功能與性能要求。為了滿足這些要求，需要修改或再開發(fā)軟件，以擴充軟件功能、增強軟件性能、改進加工效率、提高軟件的可維護性。這種情況下進行的維護活動叫做擴充與完善性維護。5擴充與完善性維護---PerfectiveMaint75預(yù)防性維護---PreventiveMaintenance預(yù)防性維護是為了提高軟件的可維護性、可靠性等，為以后進一步改進軟件打下良好基礎(chǔ)。預(yù)防性維護定義為：采用先進的軟件工程方法對需要維護的軟件或軟件中的某一部分（重新）進行設(shè)計、編制和測試。6預(yù)防性維護---PreventiveMaintena76各種維護所占比例:其它維護4%適應(yīng)性維護18%～25%改正性維護

17%～

21%擴充與完善性維護50%～60%7各種維護所占比例:其它維護4%適應(yīng)性維護改正性維護擴充778.2軟件維護的特點

--影響維護工作量的因素系統(tǒng)大小：系統(tǒng)越大，理解掌握起來越困難。系統(tǒng)越大，所執(zhí)行功能越復(fù)雜。因而需要更多的維護工作量。程序設(shè)計語言：使用強功能的程序設(shè)計語言可以控制程序的規(guī)模。語言的功能越強，生成程序的模塊化和結(jié)構(gòu)化程度越高，所需的指令數(shù)就越少，程序的可讀性越好。88.2軟件維護的特點--影響維護工作量的因素78系統(tǒng)年齡：老系統(tǒng)隨著不斷的修改，結(jié)構(gòu)越來越亂；維護人員經(jīng)常更換，程序又變得越來越難于理解許多老系統(tǒng)在當初并未按照軟件工程的要求進行開發(fā)，因而沒有文檔，或文檔太少。在長期的維護過程中文檔在許多地方與程序?qū)崿F(xiàn)變得不一致，在維護時就會遇到很大困難。數(shù)據(jù)庫技術(shù)的應(yīng)用：使用數(shù)據(jù)庫，可以簡單而有效地管理和存儲用戶程序中的數(shù)據(jù)，還可以減少生成用戶報表應(yīng)用軟件的維護工作量。9系統(tǒng)年齡：79先進的軟件開發(fā)技術(shù)：在軟件開發(fā)時，若使用能使軟件結(jié)構(gòu)比較穩(wěn)定的分析與設(shè)計技術(shù)，及程序設(shè)計技術(shù)，如面向?qū)ο蠹夹g(shù)、復(fù)用技術(shù)等，可減少大量的工作量。其它：

應(yīng)用的類型數(shù)學模型任務(wù)的難度開關(guān)與標記、IF嵌套深度、索引或下標數(shù)等 對維護工作量都有影響。許多軟件在開發(fā)時并未考慮將來的修改，為軟件的維護帶來許多問題。10先進的軟件開發(fā)技術(shù)：在軟件開發(fā)時，若使用能使軟件結(jié)構(gòu)比較80維護成本有形的軟件維護成本是花費了多少錢，無形的維護成本有更大的影響。可用的資源必須供維護任務(wù)使用,以致耽誤甚至喪失開發(fā)的良機;

一些合理的修復(fù)或修改請求不能及時安排，使得客戶不滿意；變更的結(jié)果引入新的故障，使得軟件整體質(zhì)量下降；把軟件人員抽調(diào)到維護工作中，干擾了軟件開發(fā)工作。11維護成本有形的軟件維護成本是花費了多少錢，無形的維護成本81維護工作量的模型M

是維護中消耗的總工作量P

是生產(chǎn)性工作量K

是一個經(jīng)驗常數(shù)c

是因缺乏好的設(shè)計和文檔而導致復(fù)雜性的度量d是維護人員對軟件熟悉程度的度量模型指明，如果使用了不好的軟件開發(fā)方法（未按軟件工程要求做），原來參加開發(fā)的人員或小組不能參加維護，則工作量（及成本）將按指數(shù)級增加。12維護工作量的模型M是維護中消耗的總工作量828.2.3維護中的典型問題(1)

難以跟蹤軟件版本的進化過程,軟件的變化未在文檔中反映出來.(2)難以跟蹤軟件的創(chuàng)建過程.(3)難以讀懂他人程序.(4)無文檔或不全.(5)軟件人員流動性大.(6)設(shè)計時未考慮修改需要,修改困難.維護工作無吸引力,缺乏成就感.采用軟件工程方法至少可部分地解決與維護有關(guān)的每一個問題。138.2.3維護中的典型問題(1)難以跟蹤軟件838.3軟件維護過程維護過程本質(zhì)上是修改和壓縮了的軟件定義和開發(fā)過程，而且事實上遠在提出一項維護要求之前，與軟件維護有關(guān)的工作已經(jīng)開始了。為了有效地進行軟件維護，應(yīng)事先就開始做組織工作。

首先建立維護的機構(gòu)

申明提出維護申請報告的過程及評價的過程

為每一個維護申請規(guī)定標準的處理步驟

建立維護活動的記錄保管，并規(guī)定復(fù)審的標準148.3軟件維護過程維護過程本質(zhì)上是修改和壓縮了的軟件841、維護機構(gòu)除了較大的軟件開發(fā)公司外，通常在軟件維護工作方面，并不保持一個正式的組織機構(gòu)。雖然不要求建立一個正式的維護機構(gòu)，但是在開發(fā)部門確立一個非正式的維護機構(gòu)則是非常必要的。151、維護機構(gòu)除了較大的軟件開發(fā)公司外，通常在軟件維護工作85每個維護要求都通過維護管理員轉(zhuǎn)交給相應(yīng)的系統(tǒng)管理員去評價（系統(tǒng)管理員是被指定去熟悉一小部分產(chǎn)品程序的技術(shù)人員）。系統(tǒng)管理員對維護任務(wù)做出評價之后，由變化授權(quán)人決定應(yīng)該進行的活動。16每個維護要求都通過維護管理員轉(zhuǎn)交給相應(yīng)的系統(tǒng)管理員去評價862.維護報告應(yīng)該用標準化的格式表達所有軟件維護申請（要求）。維護申請報告或稱軟件問題報告，由申請維護的用戶填寫。用戶必須完整地說明產(chǎn)生錯誤的情況，包括輸入數(shù)據(jù)、錯誤清單以及其它有關(guān)材料。如果申請的是適應(yīng)性維護或完善性維護，用戶必須提出一份修改說明書，列出所有希望的修改。172.維護報告87維護申請報告將由維護管理員和系統(tǒng)管理員來研究處理。他們應(yīng)相應(yīng)地做出軟件修改報告，指明：所需修改變動的性質(zhì)；申請修改的優(yōu)先級；為滿足某個維護申請報告，所需的工作量預(yù)計修改后的狀況.軟件修改報告應(yīng)提交給變化授權(quán)人（修改負責人），經(jīng)批準后才能開始進一步安排維護工作。18維護申請報告將由維護管理員和系統(tǒng)管理員來研究處理。883.維護的事件流193.維護的事件流89盡管維護申請的類型不同，但都要進行同樣的技術(shù)工作。修改軟件需求說明修改軟件設(shè)計設(shè)計評審對源程序做必要的修改單元測試集成測試(回歸測試)

確認測試軟件配置評審等。20盡管維護申請的類型不同，但都要進行同樣的技術(shù)工作。90

在每次軟件維護任務(wù)完成后進行情況評審，對以下問題做一總結(jié)：

(1)

在目前情況下，設(shè)計、編碼、測試中的哪一方面可以改進?

(2)

哪些維護資源應(yīng)該有但沒有?

(3)

工作中主要的或次要的障礙是什么?

(4)

從維護申請的類型來看是否應(yīng)當有預(yù)防性維護?

情況評審對將來的維護工作如何進行會產(chǎn)生重要的影響。21在每次軟件維護任務(wù)完成后進行情況評審，對以下問題做一914、維護檔案記錄①程序標識；②源語句數(shù)；③機器指令條數(shù)；④使用的程序設(shè)計語言；⑤程序安裝的日期；⑥自從安裝以來程序運行的次數(shù)；⑦自從安裝以來程序失效的次數(shù)；⑧程序變動的層次和標識；⑨因程序變動而增加的源語句數(shù)；⑽因程序變動而刪除的源語句數(shù)；⑾每個改動耗費的人時數(shù)；⑿程序改動的日期；⒀軟件工程師的名字；⒁維護要求表的標識；⒂維護類型；⒃維護開始和完成的日期；⒄累計用于維護的人時數(shù)；⒅與完成的維護相聯(lián)系的純效益。224、維護檔案記錄①程序標識；②源語句數(shù)；③機器指令條925、維護評價評價維護活動比較困難，因為缺乏可靠的數(shù)據(jù)。如果維護的檔案記錄做得比較好，可以得出一些維護“性能”方面的度量值。

(1)每次程序運行平均失效的次數(shù)；(2)用于每一類維護活動的總?cè)藭r數(shù)；(3)平均每個程序、每種語言、每種維護類型所做的程序變動數(shù)；(4)維護過程中增加或刪除一個源語句平均花費的人時數(shù)；(5)維護每種語言平均花費的人時數(shù)；(6)一張維護要求表的平均周轉(zhuǎn)時間；(7)不同維護類型所占的百分比。根據(jù)對維護工作定量度量的結(jié)果，可以做出關(guān)于開發(fā)技術(shù)、語言選擇、維護工作量規(guī)劃、資源分配及其他許多方面的決定，而且可以利用這樣的數(shù)據(jù)去分析評價維護任務(wù)。235、維護評價評價維護活動比較困難，因為缺乏可靠的數(shù)據(jù)。93程序修改的步驟及修改的副作用(自學)在軟件維護時，必然會對源程序進行修改。通常對源程序的修改不能無計劃地倉促上陣，為了正確、有效地修改,需要經(jīng)歷以下三個步驟。

分析和理解程序

修改程序

重新驗證程序24程序修改的步驟及修改的副作用(自學)在軟件維護時，必然會94分析和理解程序經(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)等；25分析和理解程序經(jīng)過分析，全面、準確、迅速地理解程序是決定95

了解數(shù)據(jù)流信息，即涉及到的數(shù)據(jù)來源何處，在哪里被使用；了解控制流信息，即執(zhí)行每條路徑的結(jié)果；理解程序的操作(使用)要求；為了容易地理解程序，要求自頂向下地理解現(xiàn)有源程序的程序結(jié)構(gòu)和數(shù)據(jù)結(jié)構(gòu)，為此可采用如下幾種方法：26

了解數(shù)據(jù)流信息，即涉及到的數(shù)據(jù)來源何處，在哪里被使用961.分析程序結(jié)構(gòu)圖

(1)搜集所有存儲該程序的文件，閱讀這些文件，記下它們包含的過程名，建立一個包括這些過程名和文件名的清單；

(2)分析各個過程的源代碼，建立一個直接調(diào)用矩陣D或調(diào)用樹。若過程i調(diào)用過程j，則D[i][j]＝1，否則D[i][j]＝0。271.分析程序結(jié)構(gòu)圖

(1)搜集所有存儲該程序的文件，97

(3)建立過程的間接調(diào)用矩陣I，即直接調(diào)用矩陣D的傳遞閉包

I＝D1∪D2∪D3∪…∪Dn

其中，n是所包含的過程總數(shù).

例如，過程i調(diào)用j，j調(diào)用k， 則D[i][j]＝1，D[j][k]＝1，

I[i][k]＝1。

(4)分析各個過程的接口，估計更改的復(fù)雜性。

28 (3)建立過程的間接調(diào)用矩陣I，即直接調(diào)用矩陣D的傳982.數(shù)據(jù)跟蹤

(1)建立各層次的程序級上的接口圖，展示各模塊或過程的調(diào)用方式和接口參數(shù)；

(2)利用數(shù)據(jù)流分析方法，對過程內(nèi)部的一些變量進行跟蹤。可獲得有關(guān)數(shù)據(jù)在過程間如何傳遞，在過程內(nèi)如何處理等信息。對于判斷問題原因特別有用。在跟蹤的過程中可在源程序中間插入自己的注釋。292.數(shù)據(jù)跟蹤

(1)建立各層次的程序級上的接口圖，展993.控制跟蹤 控制流跟蹤可采用符號執(zhí)行或?qū)嶋H動態(tài)跟蹤的方法，了解數(shù)據(jù)如何從一個輸入源到達輸出點的。4.充分閱讀和使用源程序清單和文檔，分析現(xiàn)有文檔的合理性。5.充分使用由編譯程序或匯編程序提供的交叉引用表、符號表、以及其它有用的信息。6.

如有可能，積極參加開發(fā)工作。303.控制跟蹤100修改程序?qū)Τ绦虻男薷?，必須事先做出計劃，有預(yù)謀地、周密有效地實施修改。1.設(shè)計程序的修改計劃 程序的修改計劃要考慮人員和資源的安排。小的修改可以不需要詳細的計劃，而對于需要耗時數(shù)月的修改，就需要計劃立案。31修改程序?qū)Τ绦虻男薷模仨毷孪茸龀鲇媱?，有預(yù)謀地、周密有101 在編寫有關(guān)問題解決的方案時，必須充分描述修改作業(yè)的規(guī)格說明。

規(guī)格說明信息：數(shù)據(jù)修改、處理修改、作業(yè)控制語言修改、系統(tǒng)之間接口的修改等；

維護資源：新程序版本、測試數(shù)據(jù)、所需軟件、計算機時間等；

人員；

支持：紙面、計算機媒體等。32 在編寫有關(guān)問題解決的方案時，必須充分描述修改作業(yè)的規(guī)格102 通常，可采用自頂向下的方法，在理解程序的基礎(chǔ)上，

(1)

研究程序的各個模塊、模塊的接口及數(shù)據(jù)庫，從全局的觀點，提出修改計劃。

(2)

依次地把要修改的以及那些受修改影響的模塊和數(shù)據(jù)結(jié)構(gòu)分離出來。為此，要

識別受修改影響的數(shù)據(jù)；

識別使用這些數(shù)據(jù)的程序模塊；33 通常，可采用自頂向下的方法，在理解程序的基礎(chǔ)上，

(1103

對于上面程序模塊，按是產(chǎn)生數(shù)據(jù)、修改數(shù)據(jù)、還是刪除數(shù)據(jù)進行分類；

識別對這些數(shù)據(jù)元素的外部控制信息；

識別編輯和檢查這些數(shù)據(jù)元素的地方；

隔離要修改的部分；34 對于上面程序模塊，按是產(chǎn)生數(shù)據(jù)、修改數(shù)據(jù)、還是刪104(3)

詳細地分析要修改的、以及那些受變更影響的模塊和數(shù)據(jù)結(jié)構(gòu)的內(nèi)部細節(jié)，設(shè)計修改計劃，標明新邏輯及要改動的現(xiàn)有邏輯。(4)

向用戶提供回避措施。用戶的某些業(yè)務(wù)因軟件中發(fā)生問題而中斷，為不讓系統(tǒng)長時間停止運行，需把問題局部化，在可能的范圍內(nèi)繼續(xù)開展業(yè)務(wù)。 可以采取的措施有：35(3)詳細地分析要修改的、以及那些受變更影響的模塊和數(shù)105①查找問題原因，可能情況有：

意外停機

安裝的期限到期

系統(tǒng)運行中發(fā)現(xiàn)錯誤②如果弄清了問題的原因，可通過臨時修改或改變運行控制以回避在系統(tǒng)運行時產(chǎn)生的問題。36①查找問題原因，可能情況有：1062.修改代碼，以適應(yīng)變化

在修改時，要求：

(1)

正確、有效地編寫修改代碼；

(2)

要謹慎地修改程序，盡量保持程序的風格及格式，要在程序清單上注明改動的指令；

(3)

不要刪除程序語句，除非完全肯定它是無用的；

(4)

不要試圖共用程序中已有的臨時變量或工作區(qū)，為了避免沖突或混淆用途，應(yīng)設(shè)置自己的變量；

372.修改代碼，以適應(yīng)變化

在修改時，要求：

107

(5)

插入錯誤檢測語句；

(6)

在修改過程中做好修改的詳細記錄，消除變更中任何有害的副作用（波動效應(yīng)）；3.修改程序的副作用

所謂副作用是指因修改軟件而造成的錯誤或其它不希望發(fā)生的情況。副作用有三種：修改代碼的副作用、修改數(shù)據(jù)的副作用、文檔的副作用。38 (5)插入錯誤檢測語句；

(6)在修改過程中做好修108

在修改源代碼時，都可能引入錯誤。例如，刪除或修改一個子程序、刪除或修改一個標號、刪除或修改一個標識符、改變程序代碼的時序關(guān)系、改變占用存儲的大小、改變邏輯運算符、修改文件的打開或關(guān)閉、改進程序的執(zhí)行效率，以及把設(shè)計上的改變翻譯成代碼的改變時，都容易引入錯誤。(1)修改代碼的副作用39

在修改源代碼時，都可能引入錯誤。例如，刪除或修改一個子109(2)修改數(shù)據(jù)的副作用在修改數(shù)據(jù)結(jié)構(gòu)時，有可能造成軟件設(shè)計與數(shù)據(jù)結(jié)構(gòu)不匹配，因而導致軟件出錯。數(shù)據(jù)副作用就是修改軟件信息結(jié)構(gòu)導致的結(jié)果。容易導致設(shè)計與數(shù)據(jù)不相容的錯誤可以有：

重新定義局部的或全局的常量40(2)修改數(shù)據(jù)的副作用在修改數(shù)據(jù)結(jié)構(gòu)時，有可能造成軟件110

重新定義記錄或文件的格式增大或減小一個數(shù)組或高層數(shù)據(jù)結(jié)構(gòu)的大小修改全局或公共數(shù)據(jù)重新初始化控制標志或指針重新排列輸入／輸出或子程序的參數(shù)數(shù)據(jù)副作用可以通過交叉引用表加以控制。把數(shù)據(jù)元素、記錄、文件和其它結(jié)構(gòu)聯(lián)系起來。41重新定義記錄或文件的格式111(3)文檔的副作用對數(shù)據(jù)流、軟件結(jié)構(gòu)、模塊邏輯或任何其它有關(guān)特性進行修改時，必須對相關(guān)技術(shù)文檔進行相應(yīng)修改。否則會導致文檔與程序功能不匹配，缺省條件改變，新錯誤信息不正確等錯誤。使得軟件文檔不能反映軟件的當前狀態(tài)。對于用戶來說，軟件事實上就是文檔。42(3)文檔的副作用對數(shù)據(jù)流、軟件結(jié)構(gòu)、模塊邏輯或任何112如果對可執(zhí)行軟件的修改不反映在文檔里，就會產(chǎn)生文檔的副作用。對交互輸入的順序或格式進行修改，如果沒有正確地記入文檔中，就可能引起重大的問題。過時的文檔內(nèi)容、索引和文本可能造成沖突，引起用戶失敗和不滿。因此，必須在軟件交付之前對整個軟件配置進行評審，以減少文檔的副作用。43如果對可執(zhí)行軟件的修改不反映在文檔里，就會產(chǎn)生文檔的副作113為了控制因修改而引起的副作用，要做到：

(1)按模塊把修改分組；

(2)自頂向下地安排被修改模塊的順序；

(3)每次修改一個模塊；

(4)對于每個修改了的模塊，在安排修改下一個模塊之前，要確定這個修改的副作用。可以使用交叉引用表、存儲映象表、執(zhí)行流程跟蹤等。44為了控制因修改而引起的副作用，要做到：

(1)按模塊把114重新驗證程序在將修改后的程序提交用戶之前，需要進行充分的確認和測試，以保證整個修改后程序的正確性。靜態(tài)確認

修改軟件，伴隨著引起新的錯誤的危險。為了能夠做出正確的判斷，驗證修改后的程序至少需要兩個人參加。要檢查：

45重新驗證程序在將修改后的程序提交用戶之前，需要進行充分的115

(1)

修改是否涉及到規(guī)格說明?修改結(jié)果是否符合規(guī)格說明?有沒有歪曲規(guī)格說明?

(2)

程序的修改是否足以修正軟件中的問題?源程序代碼有無邏輯錯誤?修改時有無修補失誤?

(3)

修改部分對其它部分有無不良影響(副作用)?

對軟件進行修改，常常會引發(fā)別的問題，有必要檢查修改的影響范圍。46 (1)修改是否涉及到規(guī)格說明?修改結(jié)果是否符合規(guī)116計算機確認

在進行了以上確認的基礎(chǔ)上，用計算機對修改程序進行確認測試：

(1)確認測試順序：先對修改部分進行測試，然后隔離修改部分，測試程序的未修改部分，最后再把它們集成起來進行測試。這種測試稱為回歸測試。

(2)

準備標準的測試用例。

(3)充分利用軟件工具幫助重新驗證過程。47計算機確認

在進行了以上確認的基礎(chǔ)上，用計算機對修改程序117

(4)在重新確認過程中，需邀請用戶參加。維護后的驗收──在交付新軟件之前，維護主管部門要檢驗：

(1)

全部文檔是否完備，并已更新；

(2)

所有測試用例和測試結(jié)果已經(jīng)正確記載；

(3)

記錄軟件配置所有副本的工作已經(jīng)完成；

(4)

維護工序和責任已經(jīng)確定。48 (4)在重新確認過程中，需邀請用戶參加。118從維護角度來看所需測試種類

(1)對修改事務(wù)的測試；

(2)對修改程序的測試；

(3)操作過程的測試；

(4)應(yīng)用系統(tǒng)運用過程的測試；

(5)系統(tǒng)各部分之間接口的測試；

(6)作業(yè)控制語言的測試；

(7)與系統(tǒng)軟件接口的測試；49從維護角度來看所需測試種類 (1)對修改事務(wù)的測試；119

(8)軟件系統(tǒng)之間接口的測試；

(9)安全性測試；

(10)后備／恢復(fù)過程的測試。50 (8)軟件系統(tǒng)之間接口的測試；1208.4軟件的可維護性許多軟件的維護十分困難，原因在于這些軟件的文檔不全、質(zhì)量差、開發(fā)過程不注意采用好的方法，忽視程序設(shè)計風格等。許多維護要求并不是因為程序中出錯而提出的，而是為適應(yīng)環(huán)境變化或需求變化而提出的。為了使得軟件能夠易于維護，必須考慮使軟件具有可維護性。軟件可維護性是指糾正軟件系統(tǒng)出現(xiàn)的錯誤和缺陷，以及為滿足新的要求進行修改、擴充或壓縮的容易程度。518.4軟件的可維護性許多軟件的維護十分困難，原因在于1218.4.1決定軟件可維護性的因素

1.可理解性表現(xiàn)為外來讀者理解軟件的結(jié)構(gòu)、功能、接口和內(nèi)部處理過程的難易程度。模塊化（模塊結(jié)構(gòu)良好，高內(nèi)聚，松耦合）、詳細的設(shè)計文檔、結(jié)構(gòu)化設(shè)計、程序內(nèi)部的文檔和良好的高級程序設(shè)計語言等等，都對提高軟件的可理解性有重要貢獻。2.可測試性診斷和測試的容易程度取決于軟件容易理解的程度。軟件結(jié)構(gòu)、可用的測試工具和調(diào)試工具，以及以前設(shè)計的測試過程也都是非常重要的

528.4.1決定軟件可維護性的因素1.可理解性1228.4.1決定軟件可維護性的因素3.可修改性(和第五章設(shè)計原理和啟發(fā)規(guī)則直接有關(guān))4.可移植性

把程序從一種計算機環(huán)境(硬件配置和操作系統(tǒng))轉(zhuǎn)移到

另一種計算環(huán)境的難易程度.5.可重用性指同一事物不做修改或稍加改動就在不同的環(huán)境中多次

重復(fù)使用.538.4.1決定軟件可維護性的因素3.可修改性(1238.4.2文檔文檔是影響軟件可維護性的決定因素。往往文檔比程序代碼更重要。軟件系統(tǒng)的文檔可以分為用戶文檔和系統(tǒng)文檔兩類。

----用戶文檔主要描述系統(tǒng)功能和使用方法，并不關(guān)心這些功能是怎樣實現(xiàn)的；

----系統(tǒng)文檔描述系統(tǒng)設(shè)計、實現(xiàn)和測試等各方面的內(nèi)容。548.4.2文檔文檔是影響軟件可維護性的決定因素。往124軟件文檔應(yīng)該滿足下述要求：(1)必須描述如何使用這個系統(tǒng)，沒有這種描述時即使是最簡單的系統(tǒng)也無法使用；(2)必須描述怎樣安裝和管理這個系統(tǒng)；(3)必須描述系統(tǒng)需求和設(shè)計；(4)