授課教師：梁麗軟件工程西華大學計算機與數理學院授課教師：梁麗軟件工程西華大學計算機與數理學院1第八章 軟件維護內容要點：

本章主要介紹軟件維護內容、特點、實施及提高軟件可維護性的方法。

教學重點：校正性維護、適應性維護、完善性維護、預防性維護可維護性及其量度提高可維護性方法第八章 軟件維護內容要點：2

軟件維護的概念

軟件維護活動

可維護性

提高可維護性的方法軟件維護軟件維護的概念軟件維護3軟件維護的概念

軟件維護的定義

影響維護工作量的因素

軟件維護的策略

維護成本軟件維護的概念軟件維護的定義4軟件維護的定義在軟件運行／維護階段對軟件產品進行的修改就是所謂的維護。維護的類型有四種：

改正性維護

適應性維護

完善性維護

預防性維護軟件維護的定義在軟件運行／維護階段對軟件產品進行的修改就是所5改正性維護在軟件交付使用后，因開發時測試的不徹底、不完全，必然會有部分隱藏的錯誤遺留到運行階段。這些隱藏下來的錯誤在某些特定的使用環境下就會暴露出來。為了識別和糾正軟件錯誤、改正軟件性能上的缺陷、排除實施中的誤使用，應當進行的診斷和改正錯誤的過程就叫做改正性維護。改正性維護在軟件交付使用后，因開發時測試的不徹底、不完全，必6適應性維護在使用過程中，

外部環境（新的硬、軟件配置）

數據環境（數據庫、數據格式、數據輸入/輸出方式、數據存儲介質）可能發生變化。為使軟件適應這種變化，而去修改軟件的過程就叫做適應性維護。

適應性維護在使用過程中，7完善性維護在軟件的使用過程中，用戶往往會對軟件提出新的功能與性能要求。為了滿足這些要求，需要修改或再開發軟件，以擴充軟件功能、增強軟件性能、改進加工效率、提高軟件的可維護性。這種情況下進行的維護活動叫做完善性維護。完善性維護在軟件的使用過程中，用戶往往會對軟件提出新的功能與8實踐表明，在幾種維護活動中，完善性維護所占的比重最大。即大部分維護工作是改變和加強軟件，而不是糾錯。完善性維護不一定是救火式的緊急維修，而可以是有計劃、有預謀的一種再開發活動。事實證明，來自用戶要求擴充、加強軟件功能、性能的維護活動約占整個維護工作的50％。實踐表明，在幾種維護活動中，完善性維護所占的比重最大。即大部9預防性維護預防性維護是為了提高軟件的可維護性、可靠性等，為以后進一步改進軟件打下良好基礎。預防性維護定義為：采用先進的軟件工程方法對需要維護的軟件或軟件中的某一部分（重新）進行設計、編制和測試。預防性維護預防性維護是為了提高軟件的可維護性、可靠性等，為以10在整個軟件維護階段所花費的全部工作量中，完善性維護占了幾乎一半的工作量。軟件維護活動所花費的工作占整個生存期工作量的70%以上，這是由于在漫長的軟件運行過程中需要不斷對軟件進行修改，以改正新發現的錯誤、適應新的環境和用戶新的要求，這些修改需要花費很多精力和時間，而且有時會引入新的錯誤。在整個軟件維護階段所花費的全部工作量中，完善性維護占了幾乎一11

三類維護占維護在軟件生存期

總維護比例 所占比例三類維護占維護在軟件生存期

總維護12影響維護工作量的因素在軟件的維護過程中，需要花費大量的工作量，從而直接影響了軟件維護的成本。應當考慮有哪些因素影響軟件維護的工作量，相應應該采取什么維護策略，才能有效地維護軟件并控制維護的成本。影響維護工作量的因素在軟件的維護過程中，需要花費大量的工作量13系統大小：系統越大，理解掌握起來越困難。系統越大，所執行功能越復雜。因而需要更多的維護工作量。程序設計語言：使用強功能的程序設計語言可以控制程序的規模。語言的功能越強，生成程序的模塊化和結構化程度越高，所需的指令數就越少，程序的可讀性越好。系統大小：系統越大，理解掌握起來越困難。系統越大，所執行功能14系統年齡：老系統隨著不斷的修改，結構越來越亂；維護人員經常更換，程序又變得越來越難于理解。許多老系統在當初并未按照軟件工程的要求進行開發，因而沒有文檔，或文檔太少。在長期的維護過程中文檔在許多地方與程序實現變得不一致，在維護時就會遇到很大困難。系統年齡：15數據庫技術的應用：使用數據庫，可以簡單而有效地管理和存儲用戶程序中的數據，還可以減少生成用戶報表應用軟件的維護工作量。先進的軟件開發技術：在軟件開發時，若使用能使軟件結構比較穩定的分析與設計技術，及程序設計技術，如面向對象技術、復用技術等，可減少大量的工作量。數據庫技術的應用：使用數據庫，可以簡單而有效地管理和存儲用戶16其它：應用的類型數學模型任務的難度開關與標記、IF嵌套深度、索引或下標數等 對維護工作量都有影響。許多軟件在開發時并未考慮將來的修改，為軟件的維護帶來許多問題。其它：17軟件維護的策略改正性維護

通常要生成100％可靠的軟件并不一定合算，成本太高。但通過使用新技術，可大大減少進行改正性維護的需要。

這些技術包括：數據庫管理系統、軟件開發環境、程序自動生成系統、較高級(第四代)的語言。以及新的開發方法、軟件復用、防錯程序設計及周期性維護審查等。軟件維護的策略改正性維護

18適應性維護

這一類維護不可避免，可以控制。

(1)

在配置管理時，把硬件、操作系統和其它相關環境因素的可能變化考慮在內。

(2)

把與硬件、操作系統，以及其它外圍設備有關的程序歸到特定的程序模塊中。

(3)使用內部程序列表、外部文件，以及處理的例行程序包，可為維護時修改程序提供方便。適應性維護

19完善性維護

利用前兩類維護中列舉的方法，也可以減少這一類維護。特別是數據庫管理系統、程序生成器、應用軟件包，可減少維護工作量。

此外，建立軟件系統的原型，把它在實際系統開發之前提供給用戶。用戶通過研究原型，進一步完善他們的功能要求，就可以減少以后完善性維護的需要。完善性維護

20維護成本有形的軟件維護成本是花費了多少錢，無形的維護成本有更大的影響。

一些合理的修復或修改請求不能及時安排，使得客戶不滿意；變更的結果引入新的故障，使得軟件整體質量下降；把軟件人員抽調到維護工作中，干擾了軟件開發工作。維護成本有形的軟件維護成本是花費了多少錢，無形的維護成本有更21軟件維護的代價是降低了生產率，在做老程序的維護時非常明顯。例如，開發每一行源代碼耗資25美元，維護每一行源代碼需要耗資1000美元。維護工作量包括生產性活動（如分析和評價、設計修改和實現）和“輪轉”活動（如力圖理解代碼在做什么、試圖判明數據結構、接口特性、性能界限等）。軟件維護的代價是降低了生產率，在做老程序的維護時非常明顯。22維護工作量的模型

M是維護中消耗的總工作量p是上面描述的生產性工作量K是一個經驗常數c是因缺乏好的設計和文檔而導致復雜性的度量d是對軟件熟悉程度的度量。維護工作量的模型M是維護中消耗的總工作量23模型指明，如果使用了不好的軟件開發方法（未按軟件工程要求做），原來參加開發的人員或小組不能參加維護，則工作量（及成本）將按指數級增加。模型指明，如果使用了不好的軟件開發方法（未按軟件工程要求做）24軟件維護活動為了有效地進行軟件維護，應事先就開始做組織工作。首先建立維護的機構申明提出維護申請報告的過程及評價的過程為每一個維護申請規定標準的處理步驟建立維護活動的登記制度以及規定評價和評審的標準。軟件維護活動為了有效地進行軟件維護，應事先就開始做組織工作。25維護機構除了較大的軟件開發公司外，通常在軟件維護工作方面，并不保持一個正式的組織機構。雖然不要求建立一個正式的維護機構，但是在開發部門確立一個非正式的維護機構則是非常必要的。維護機構除了較大的軟件開發公司外，通常在軟件維護工作方面，并26

軟件維護的機構

軟件維護的機構27維護申請提交給維護管理員，他把申請交給某個系統監督員去評價。一旦做出評價，由修改負責人確定如何進行修改。在修改程序的過程中，由配置管理員嚴格把關，控制修改的范圍，對軟件配置進行審計。在維護之前，就把責任明確下來，可以減少維護過程中的混亂。維護申請提交給維護管理員，他把申請交給某個系統監督員去評價。28軟件維護申請報告維護申請報告或稱軟件問題報告，由申請維護的用戶填寫。用戶必須完整地說明產生錯誤的情況，包括輸入數據、錯誤清單以及其它有關材料。如果申請的是適應性維護或完善性維護，用戶必須提出一份修改說明書，列出所有希望的修改。軟件維護申請報告維護申請報告或稱軟件問題報告，由申請維護的用29

維護申請報告將由維護管理員和系統監督員來研究處理。他們應相應地做出軟件修改報告，指明：所需修改變動的性質；申請修改的優先級；為滿足某個維護申請報告，所需的工作量；預計修改后的狀況.

維護申請報告將由維護管理員和系統監督員來研究處理。30軟件修改報告應提交修改負責人，經批準后才能開始進一步安排維護工作。軟件修改報告應提交修改負責人，經批準后才能開始進一步安排維護31軟件維護工作流程軟件維護工作流程32盡管維護申請的類型不同，但都要進行同樣的技術工作。

修改軟件需求說明修改軟件設計設計評審對源程序做必要的修改單元測試集成測試(回歸測試)確認測試軟件配置評審等。

盡管維護申請的類型不同，但都要進行同樣的技術工作。33在每次軟件維護任務完成后進行情況評審，對以下問題做一總結：

(1)

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

(2)哪些維護資源應該有但沒有?

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

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

情況評審對將來的維護工作如何進行會產生重要的影響。在每次軟件維護任務完成后進行情況評審，對以下問題做一總結：

34維護檔案記錄程序名稱源程序語句條數機器代碼指令條數所用的程序設計語言程序安裝的日期程序安裝后的運行次數與程序安裝后運行次數有關的處理故障次數程序改變的層次及名稱維護檔案記錄程序名稱35

修改程序增加的源程序語句條數修改程序減少的源程序語句條數每次修改所付出的“人時”數修改程序的日期軟件維護人員的姓名維護申請報告的名稱、維護類型維護開始時間和維護結束時間、花費在維護上的累計“人時”數維護工作的凈收益等。

修改程序增加的源程序語句條數36維護評價評價維護活動比較困難，因為缺乏可靠的數據。如果維護的檔案記錄做得比較好，可以得出一些維護“性能”方面的度量值。每次程序運行時的平均出錯次數；花費在每類維護上的總“人時”數；每個程序、每種語言、每種維護類型的程序平均修改次數；維護評價評價維護活動比較困難，因為缺乏可靠的數據。37因為維護，增加或刪除每個源程序語句所花費的平均“人時”數；用于每種語言的平均“人時”數；維護申請報告的平均處理時間；各類維護申請的百分比。因為維護，增加或刪除每個源程序語句所花費的平均“人時”數；38軟件可維護性許多軟件的維護十分困難，原因在于這些軟件的文檔不全、質量差、開發過程不注意采用好的方法，忽視程序設計風格等。許多維護要求并不是因為程序中出錯而提出的，而是為適應環境變化或需求變化而提出的。為了使得軟件能夠易于維護，必須考慮使軟件具有可維護性。軟件可維護性許多軟件的維護十分困難，原因在于這些軟件的文檔不39

軟件可維護性的定義軟件可維護性是指糾正軟件系統出現的錯誤和缺陷，以及為滿足新的要求進行修改、擴充或壓縮的容易程度。可維護性、可使用性、可靠性是衡量軟件質量的主要質量特性，也是用戶十分關心的幾個方面。軟件的可維護性是軟件開發階段各個時期的關鍵目標。

軟件可維護性的定義軟件可維護性是指糾正軟件系統出現的錯40目前廣泛使用的是用如下的七個特性來衡量程序的可維護性。

可理解性 可使用性 可測試性 可移植性 可修改性 效率 可靠性而且對于不同類型的維護，這七種特性的側重點也不相同。目前廣泛使用的是用如下的七個特性來衡量程序的可維護性。41在各類維護中的側重點

在各類維護中的側重點42這些質量特性通常體現在軟件產品的許多方面;為使每一個質量特性都達到預定的要求，需要在軟件開發的各個階段采取相應的措施加以保證。這些質量要求要滲透到而各開發階段的各個步驟當中。因此，軟件的可維護性是產品投入運行以前各階段面向上述各質量特性要求進行開發的最終結果。這些質量特性通常體現在軟件產品的許多方面;43可維護性的度量人們一直期望對軟件的可維護性做出定量度量，但要做到這一點并不容易。常用的度量一個可維護的程序的七種特性的方法。就是質量檢查表質量測試質量標準可維護性的度量人們一直期望對軟件的可維護性做出定量度量，但要44質量檢查表是用于測試程序中某些質量特性是否存在的一個問題清單。評價者針對檢查表上的每一個問題，依據自己的定性判斷，回答“Yes”或者“No”。質量測試與質量標準則用于定量分析和評價程序的質量。由于許多質量特性是相互抵觸的，要考慮幾種不同的度量標準，相應地去度量不同的質量特性。質量檢查表是用于測試程序中某些質量特性是否存在的一個問題清單451.可理解性可理解性表明人們通過閱讀源代碼和相關文檔，了解程序功能及其如何運行的容易程度。一個可理解的程序應具備以下一些特性：模塊化，風格一致性，不使用令人捉摸不定或含糊不清的代碼，使用有意義的數據名和過程名，結構化，完整性等。1.可理解性可理解性表明人們通過閱讀源代碼和相關文檔，了解462.可靠性可靠性表明一個程序按照用戶的要求和設計目標，在給定的一段時間內正確執行的概率。2.可靠性可靠性表明一個程序按照用戶的要求和設計目標，在給47度量可靠性的方法根據程序錯誤統計數字，進行可靠性預測。常用方法是利用一些可靠性模型，根據程序測試時發現并排除的錯誤數預測平均失效間隔時間。

根據程序復雜性，預測軟件可靠性。

用程序復雜性預測可靠性，前提條件是可靠性與復雜性有關。因此可用復雜性預測出錯率。程序復雜性度量標準可用于預測哪些模塊最可能發生錯誤，以及可能出現的錯誤類型。度量可靠性的方法根據程序錯誤統計數字，進行可靠性預測。常483.可測試性可測試性表明論證程序正確性的容易程度。程序越簡單，證明其正確性就越容易。而且設計合用的測試用例，取決于對程序的全面理解。一個可測試的程序應當是可理解的，可靠的，簡單的。用于可測試性度量的檢查項目如下：程序是否模塊化?結構是否良好?3.可測試性可測試性表明論證程序正確性的容易程度。程序越簡49程序是否可理解?程序是否可靠?程序是否能顯示任意中間結果?程序是否能以清楚的方式描述它的輸出?程序是否能及時地按照要求顯示所有的輸入?程序是否有跟蹤及顯示邏輯控制流程的能力?

程序是否能從檢查點再啟動?程序是否能顯示帶說明的錯誤信息?程序是否可理解?程序是否可靠?504.可修改性可修改性表明程序容易修改的程度。一個可修改的程序應當是可理解的、通用的、靈活的、簡單的。通用性是指程序適用于各種功能變化而無需修改。靈活性是指能夠容易地對程序進行修改4.可修改性可修改性表明程序容易修改的程度。51測試可修改性的一種定量方法是修改練習。其基本思想是通過做幾個簡單的修改，來評價修改的難度。測試可修改性的一種定量方法是修改練習。其基本思想是通過做幾個525.可移植性可移植性表明程序轉移到一個新的計算環境的可能性的大小。或者它表明程序可以容易地、有效地在各種各樣的計算環境中運行的容易程度。一個可移植的程序應具有結構良好、靈活、不依賴于某一具體計算機或操作系統的性能。用于可移植性度量的檢查項目如下：5.可移植性可移植性表明程序轉移到一個新的計算環境的可能性53

是否是用高級的獨立于機器的語言來編寫程序?是否使用廣泛使用的標準化的程序設計語言來編寫程序?是否僅使用了這種語言的標準版本和特性?程序中是否使用了標準的普遍使用的庫功能和子程序?程序中是否極少使用或根本不使用操作系統的功能?是否是用高級的獨立于機器的語言來編寫程序?54程序在執行之前是否初始化內存?程序在執行之前是否測定當前的輸入／輸出設備?程序是否把與機器相關的語句分離了出來，集中放在了一些單獨的程序模塊中，并有說明文件?

程序是否結構化?并允許在小一些的計算機上分段(覆蓋)運行?程序中是否避免了依賴于字母數字或特殊字符的內部位表示?程序在執行之前是否初始化內存?556.效率效率表明一個程序能執行預定功能而又不浪費機器資源的程度。這些機器資源包括內存容量、外存容量、通道容量和執行時間。用于效率度量的檢查項目如下：程序是否模塊化?結構是否良好?是否消除了無用的標號與表達式，以充分發揮編譯器優化作用?6.效率效率表明一個程序能執行預定功能而又不浪費機器資源的56程序的編譯器是否有優化功能?是否把特殊子程序和錯誤處理子程序都歸入了單獨的模塊中?是否以快速的數學運算代替了較慢的數學運算?是否盡可能地使用了整數運算，而不是實數運算?是否在表達式中避免了混合數據類型的使用，消除了不必要的類型轉換?程序的編譯器是否有優化功能?57程序是否避免了非標準的函數或子程序的調用?在幾條分支結構中，是否最有可能為“真”的分支首先得到測試?在復雜的邏輯條件中，是否最有可能為“真“的表達式首先得到測試?程序是否避免了非標準的函數或子程序的調用?587.可使用性從用戶觀點出發，可使用性定義為程序方便、實用、及易于使用的程度。一個可使用的程序應是易于使用的、能允許用戶出錯和改變，并盡可能不使用戶陷入混亂狀態的程序。用于可使用性度量的檢查項目如下：程序是否具有自描述性?7.可使用性從用戶觀點出發，可使用性定義為程序方便、實用、59

程序是否能始終如一地按照用戶的要求運行?程序是否讓用戶對數據處理有一個滿意的和適當的控制?程序是否容易學會使用?程序是否使用數據管理系統來自動地處理事務性工作和管理格式化、地址分配及存儲器組織。程序是否具有容錯性?程序是否靈活?程序是否能始終如一地按照用戶的要求運行?60其它間接定量度量可維護性的方法問題識別的時間；因管理活動拖延的時間；收集維護工具的時間；分析、診斷問題的時間；修改規格說明的時間；具體的改錯或修改的時間；局部測試的時間；集成或回歸測試的時間；維護的評審時間；其它間接定量度量可維護性的方法問題識別的時間；61這些數據反映了維護全過程中檢錯－糾錯－驗證的周期，即從檢測出軟件存在的問題開始至修正它們并經回歸測試驗證這段時間。可以粗略地認為，這個周期越短，維護越容易。這些數據反映了維護全過程中檢錯－糾錯－驗證的周期，即從檢測出62提高可維護性的方法建立明確的軟件質量目標和優先級使用提高軟件質量的技術和工具進行明確的質量保證審查選擇可維護的程序設計語言改進程序的文檔提高可維護性的方法建立明確的軟件質量目標和優先級63建立明確的軟件質量目標和優先級一個可維護的程序應是可理解的、可靠的、可測試的、可修改的、可移植的、效率高的、可使用的。要實現這所有的目標，需要付出很大的代價，而且也不一定行得通。某些質量特性是相互促進的，例如可理解性和可測試性、可理解性和可修改性。建立明確的軟件質量目標和優先級一個可維護的程序應是可理解的、64

另一些質量特性是相互抵觸的，如效率和可移植性、效率和可修改性等。每一種質量特性的相對重要性應隨程序的用途及計算環境的不同而不同。例如，對編譯程序來說，可能強調效率；但對管理信息系統來說，則可能強調可使用性和可修改性。應當對程序的質量特性，在提出目標的同時還必須規定它們的優先級。

另一些質量特性是相互抵觸的，如效率和可移植性、效率和可修改65使用提高軟件質量的技術和工具模塊化

如果需要改變某個模塊的功能，則只要改變這個模塊，對其它模塊影響很小；如果需要增加程序的某些功能，則僅需增加完成這些功能的新的模塊或模塊層；程序的測試與重復測試比較容易；程序錯誤易于定位和糾正；

使用提高軟件質量的技術和工具模塊化66結構化程序設計程序被劃分成分層的模塊結構；模塊調用控制必須從模塊的入口點進入，從其出口點退出。模塊的控制結構僅限于順序、選擇、重復三種，且沒有GOTO語句。每個程序變量只用于唯一的程序目的，而且變量的作用范圍應是明確的、有限制的。結構化程序設計67

使用結構化程序設計技術，提高現有系統的可維護性采用備用件的方法──用一個新的結構良好的模塊替換掉整個要修改的模塊。采用自動重建結構和重新格式化的工具(結構更新技術)──把非結構化代碼轉換成良好結構代碼。改進現有程序的不完善的文檔──建立或補充系統說明書、設計文檔、模塊說明書、以及在源程序中插入必要的注釋。

使用結構化程序設計技術，提高現有系統的可維護性68進行明確的質量保證審查質量保證審查對于獲得和維持軟件的質量，是一個很有用的技術。審查可以用來檢測在開發和維護階段內發生的質量變化。一旦檢測出問題來，就可以采取措施來糾正，以控制不斷增長的軟件維護成本，延長軟件系統的有效生命期。進行明確的質量保證審查質量保證審查對于獲得和維持軟件的質量，69保證軟件質量的最佳方法是在軟件開發的最初階段把質量要求考慮進去，并在開發過程每一階段的終點，設置檢查點進行檢查。檢查的目的是要證實，已開發的軟件是否符合標準，是否滿足規定的質量需求。在不同的檢查點，檢查的重點不完全相同。1.在檢查點進行復審保證軟件質量的最佳方法是在軟件開發的最初階段把質量要求考慮進70軟件開發期間各個檢查點的檢查重點軟件開發期間各個檢查點的檢查重點71在設計階段，檢查重點是可理解性、可修改性、可測試性。可理解性檢查的重點是程序的復雜性。對每個模塊可用McCabe環路來計算模塊的復雜性，若大于10，則需重新設計。可以使用各種質量特性檢查表，或用度量標準來檢查可維護性。審查小組可以采用人工測試一類的方式，進行審查。在設計階段，檢查重點是可理解性、可修改性、可測試性。722.驗收檢查驗收檢查是一個特殊的檢查點的檢查，是交付使用前的最后一次檢查，驗收檢查實際上是驗收測試的一部分，只不過它是從維護的角度提出驗收的條件和標準。驗收檢查必須遵循的最小驗收標準。2.驗收檢查驗收檢查是一個特殊的檢查點的檢查，是交付使用前73(1)需求和規范標準

①需求應當以可測試的術語進行書寫，排列優先次序和定義；

②區分必須的、任選的、將來的需求；

③包括對系統運行時的計算機設備的需求；對維護、測試、操作、以及維護人員的需求；對測試工具等的需求。(1)需求和規范標準74(2)設計標準 ①程序應設計成分層的模塊結構。每個模塊應完成唯一的功能，并達到高內聚、低耦合；

②通過一些知道預期變化的實例，說明設計的可擴充性、可縮減性和可適應性。(2)設計標準75(3)源代碼標準 ①盡可能使用最高級的程序設計語言，且只使用語言的標準版本； ②所有的代碼都必須具有良好的結構； ③所有的代碼都必須文檔化，在注釋中說明它的輸入、輸出、以及便于測試／再測試的一些特點與風格。(3)源代碼標準76(4)文檔標準

文檔中應說明

程序的輸入／輸出使用的方法／算法錯誤恢復方法所有參數的范圍缺省條件等。(4)文檔標準77

3.周期性地維護審查檢查點復查和驗收檢查，可用來保證新軟件系統的可維護性。對已有的軟件系統，則應當進行周期性的維護檢查。軟件在運行期間進行修改，會導致軟件質量有變壞的危險，破壞程序概念的完整性。必須定期檢查，對軟件做周期性的維護審查，以跟蹤軟件質量的變化。

3.周期性地維護審查檢查點復查和驗收檢查，可用來保證新78周期性維護審查實際上是開發階段檢查點復查的繼續，并且采用的檢查方法、檢查內容都是相同的。維護審查的結果可以同以前的維護審查的結果，以前的驗收檢查的結果、檢查點檢查的結果相比較，任何一種改變都表明在軟件質量上或其它類型的問題上可能起了變化。對于改變的原因應當進行分析。周期性維護審查實際上是開發階段檢查點復查的繼續，并且采用的檢79

4.

對軟件包進行檢查軟件包是一種標準化的，可為不同單位、不同用戶使用的軟件。一般源代碼和程序文檔不會提供給用戶。對軟件包的維護采取以下方法。使用單位的維護人員首先要仔細分析、研究賣主提供的用戶手冊、操作手冊、培訓教程等，以及賣方提供的驗收測試報告等。

4.對軟件包進行檢查軟件包是一種標準化的，可為不同單位、80在此基礎上，深入了解本單位的希望和要求，編制軟件包的檢驗程序。

檢查軟件包程序所執行的功能是否與用戶的要求和條件相一致。為了建立這個程序，維護人員可以利用賣方提供的驗收測試實例，還可以自己重新設計新的測試實例。根據測試結果，檢查和驗證軟件包的參數或控制結構，以完成軟件包的維護。在此基礎上，深入了解本單位的希望和要求，編制軟件包的檢驗程81選擇可維護的程序設計語言程序設計語言的選擇，對程序的可維護性影響很大。選擇可維護的程序設計語言程序設計語言的選擇，對程序的可維護性82機器語言

匯編語言

高級語言查詢語言

(FORTRAN、報表生成語言

COBOL等)圖象語言應用生成語言機器語言匯編語言高級語言查詢語言83改進程序的文檔程序文檔是對程序總目標、程序各組成部分之間的關系、程序設計策略、程序實現過程的歷史數據等的說明和補充。即使是一個十分簡單的程序，要想有效地、高效率地維護它，也需要編制文檔來解釋其目的及任務。改進程序的文檔程序文檔是對程序總目標、程序各組成部分之間的關84對于程序維護人員來說，要想按程序編制人員的意圖重新改造程序，并對今后變化的可能性進行估計，缺了文檔是不行的。因此，為了維護程序，人們必須閱讀和理解文檔。另外，在軟件維護階段，利用歷史文檔，可以大大簡化維護工作。通過了解原設計思想，可以判斷出錯之處，指導維護人員選擇適當的方法修改代碼而不危及系統的完整性。對于程序維護人員來說，要想按程序編制人員的意圖重新改造程序，85歷史文檔有三種：

系統開發日志錯誤記載系統維護日志歷史文檔有三種：86系統開發日志：記錄了軟件開發的目標，優先次序，設計實現方案，使用的測試技術和工具，開發進程中出現的問題和解決辦法。這些對維護活動具有極大的參照價值。運行日志：記錄軟件每天的運行情況,出錯歷史、類型，發生錯誤的現場及條件。運行日志是跟蹤軟件狀態，合理評價軟件質量，提出和預測維護要求的重要依據。系統維護日志：即條件修改報告系統開發日志：記錄了軟件開發的目標，優先次序，設計實現方案，87授課教師：梁麗軟件工程西華大學計算機與數理學院授課教師：梁麗軟件工程西華大學計算機與數理學院88第八章 軟件維護內容要點：

本章主要介紹軟件維護內容、特點、實施及提高軟件可維護性的方法。

教學重點：校正性維護、適應性維護、完善性維護、預防性維護可維護性及其量度提高可維護性方法第八章 軟件維護內容要點：89

軟件維護的概念

軟件維護活動

可維護性

提高可維護性的方法軟件維護軟件維護的概念軟件維護90軟件維護的概念

軟件維護的定義

影響維護工作量的因素

軟件維護的策略

維護成本軟件維護的概念軟件維護的定義91軟件維護的定義在軟件運行／維護階段對軟件產品進行的修改就是所謂的維護。維護的類型有四種：

改正性維護

適應性維護

完善性維護

預防性維護軟件維護的定義在軟件運行／維護階段對軟件產品進行的修改就是所92改正性維護在軟件交付使用后，因開發時測試的不徹底、不完全，必然會有部分隱藏的錯誤遺留到運行階段。這些隱藏下來的錯誤在某些特定的使用環境下就會暴露出來。為了識別和糾正軟件錯誤、改正軟件性能上的缺陷、排除實施中的誤使用，應當進行的診斷和改正錯誤的過程就叫做改正性維護。改正性維護在軟件交付使用后，因開發時測試的不徹底、不完全，必93適應性維護在使用過程中，

外部環境（新的硬、軟件配置）

數據環境（數據庫、數據格式、數據輸入/輸出方式、數據存儲介質）可能發生變化。為使軟件適應這種變化，而去修改軟件的過程就叫做適應性維護。

適應性維護在使用過程中，94完善性維護在軟件的使用過程中，用戶往往會對軟件提出新的功能與性能要求。為了滿足這些要求，需要修改或再開發軟件，以擴充軟件功能、增強軟件性能、改進加工效率、提高軟件的可維護性。這種情況下進行的維護活動叫做完善性維護。完善性維護在軟件的使用過程中，用戶往往會對軟件提出新的功能與95實踐表明，在幾種維護活動中，完善性維護所占的比重最大。即大部分維護工作是改變和加強軟件，而不是糾錯。完善性維護不一定是救火式的緊急維修，而可以是有計劃、有預謀的一種再開發活動。事實證明，來自用戶要求擴充、加強軟件功能、性能的維護活動約占整個維護工作的50％。實踐表明，在幾種維護活動中，完善性維護所占的比重最大。即大部96預防性維護預防性維護是為了提高軟件的可維護性、可靠性等，為以后進一步改進軟件打下良好基礎。預防性維護定義為：采用先進的軟件工程方法對需要維護的軟件或軟件中的某一部分（重新）進行設計、編制和測試。預防性維護預防性維護是為了提高軟件的可維護性、可靠性等，為以97在整個軟件維護階段所花費的全部工作量中，完善性維護占了幾乎一半的工作量。軟件維護活動所花費的工作占整個生存期工作量的70%以上，這是由于在漫長的軟件運行過程中需要不斷對軟件進行修改，以改正新發現的錯誤、適應新的環境和用戶新的要求，這些修改需要花費很多精力和時間，而且有時會引入新的錯誤。在整個軟件維護階段所花費的全部工作量中，完善性維護占了幾乎一98

三類維護占維護在軟件生存期

總維護比例 所占比例三類維護占維護在軟件生存期

總維護99影響維護工作量的因素在軟件的維護過程中，需要花費大量的工作量，從而直接影響了軟件維護的成本。應當考慮有哪些因素影響軟件維護的工作量，相應應該采取什么維護策略，才能有效地維護軟件并控制維護的成本。影響維護工作量的因素在軟件的維護過程中，需要花費大量的工作量100系統大小：系統越大，理解掌握起來越困難。系統越大，所執行功能越復雜。因而需要更多的維護工作量。程序設計語言：使用強功能的程序設計語言可以控制程序的規模。語言的功能越強，生成程序的模塊化和結構化程度越高，所需的指令數就越少，程序的可讀性越好。系統大小：系統越大，理解掌握起來越困難。系統越大，所執行功能101系統年齡：老系統隨著不斷的修改，結構越來越亂；維護人員經常更換，程序又變得越來越難于理解。許多老系統在當初并未按照軟件工程的要求進行開發，因而沒有文檔，或文檔太少。在長期的維護過程中文檔在許多地方與程序實現變得不一致，在維護時就會遇到很大困難。系統年齡：102數據庫技術的應用：使用數據庫，可以簡單而有效地管理和存儲用戶程序中的數據，還可以減少生成用戶報表應用軟件的維護工作量。先進的軟件開發技術：在軟件開發時，若使用能使軟件結構比較穩定的分析與設計技術，及程序設計技術，如面向對象技術、復用技術等，可減少大量的工作量。數據庫技術的應用：使用數據庫，可以簡單而有效地管理和存儲用戶103其它：應用的類型數學模型任務的難度開關與標記、IF嵌套深度、索引或下標數等 對維護工作量都有影響。許多軟件在開發時并未考慮將來的修改，為軟件的維護帶來許多問題。其它：104軟件維護的策略改正性維護

通常要生成100％可靠的軟件并不一定合算，成本太高。但通過使用新技術，可大大減少進行改正性維護的需要。

這些技術包括：數據庫管理系統、軟件開發環境、程序自動生成系統、較高級(第四代)的語言。以及新的開發方法、軟件復用、防錯程序設計及周期性維護審查等。軟件維護的策略改正性維護

105適應性維護

這一類維護不可避免，可以控制。

(1)

在配置管理時，把硬件、操作系統和其它相關環境因素的可能變化考慮在內。

(2)

把與硬件、操作系統，以及其它外圍設備有關的程序歸到特定的程序模塊中。

(3)使用內部程序列表、外部文件，以及處理的例行程序包，可為維護時修改程序提供方便。適應性維護

106完善性維護

利用前兩類維護中列舉的方法，也可以減少這一類維護。特別是數據庫管理系統、程序生成器、應用軟件包，可減少維護工作量。

此外，建立軟件系統的原型，把它在實際系統開發之前提供給用戶。用戶通過研究原型，進一步完善他們的功能要求，就可以減少以后完善性維護的需要。完善性維護

107維護成本有形的軟件維護成本是花費了多少錢，無形的維護成本有更大的影響。

一些合理的修復或修改請求不能及時安排，使得客戶不滿意；變更的結果引入新的故障，使得軟件整體質量下降；把軟件人員抽調到維護工作中，干擾了軟件開發工作。維護成本有形的軟件維護成本是花費了多少錢，無形的維護成本有更108軟件維護的代價是降低了生產率，在做老程序的維護時非常明顯。例如，開發每一行源代碼耗資25美元，維護每一行源代碼需要耗資1000美元。維護工作量包括生產性活動（如分析和評價、設計修改和實現）和“輪轉”活動（如力圖理解代碼在做什么、試圖判明數據結構、接口特性、性能界限等）。軟件維護的代價是降低了生產率，在做老程序的維護時非常明顯。109維護工作量的模型

M是維護中消耗的總工作量p是上面描述的生產性工作量K是一個經驗常數c是因缺乏好的設計和文檔而導致復雜性的度量d是對軟件熟悉程度的度量。維護工作量的模型M是維護中消耗的總工作量110模型指明，如果使用了不好的軟件開發方法（未按軟件工程要求做），原來參加開發的人員或小組不能參加維護，則工作量（及成本）將按指數級增加。模型指明，如果使用了不好的軟件開發方法（未按軟件工程要求做）111軟件維護活動為了有效地進行軟件維護，應事先就開始做組織工作。首先建立維護的機構申明提出維護申請報告的過程及評價的過程為每一個維護申請規定標準的處理步驟建立維護活動的登記制度以及規定評價和評審的標準。軟件維護活動為了有效地進行軟件維護，應事先就開始做組織工作。112維護機構除了較大的軟件開發公司外，通常在軟件維護工作方面，并不保持一個正式的組織機構。雖然不要求建立一個正式的維護機構，但是在開發部門確立一個非正式的維護機構則是非常必要的。維護機構除了較大的軟件開發公司外，通常在軟件維護工作方面，并113

軟件維護的機構

軟件維護的機構114維護申請提交給維護管理員，他把申請交給某個系統監督員去評價。一旦做出評價，由修改負責人確定如何進行修改。在修改程序的過程中，由配置管理員嚴格把關，控制修改的范圍，對軟件配置進行審計。在維護之前，就把責任明確下來，可以減少維護過程中的混亂。維護申請提交給維護管理員，他把申請交給某個系統監督員去評價。115軟件維護申請報告維護申請報告或稱軟件問題報告，由申請維護的用戶填寫。用戶必須完整地說明產生錯誤的情況，包括輸入數據、錯誤清單以及其它有關材料。如果申請的是適應性維護或完善性維護，用戶必須提出一份修改說明書，列出所有希望的修改。軟件維護申請報告維護申請報告或稱軟件問題報告，由申請維護的用116

維護申請報告將由維護管理員和系統監督員來研究處理。他們應相應地做出軟件修改報告，指明：所需修改變動的性質；申請修改的優先級；為滿足某個維護申請報告，所需的工作量；預計修改后的狀況.

維護申請報告將由維護管理員和系統監督員來研究處理。117軟件修改報告應提交修改負責人，經批準后才能開始進一步安排維護工作。軟件修改報告應提交修改負責人，經批準后才能開始進一步安排維護118軟件維護工作流程軟件維護工作流程119盡管維護申請的類型不同，但都要進行同樣的技術工作。

修改軟件需求說明修改軟件設計設計評審對源程序做必要的修改單元測試集成測試(回歸測試)確認測試軟件配置評審等。

盡管維護申請的類型不同，但都要進行同樣的技術工作。120在每次軟件維護任務完成后進行情況評審，對以下問題做一總結：

(1)

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

(2)哪些維護資源應該有但沒有?

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

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

情況評審對將來的維護工作如何進行會產生重要的影響。在每次軟件維護任務完成后進行情況評審，對以下問題做一總結：

121維護檔案記錄程序名稱源程序語句條數機器代碼指令條數所用的程序設計語言程序安裝的日期程序安裝后的運行次數與程序安裝后運行次數有關的處理故障次數程序改變的層次及名稱維護檔案記錄程序名稱122

修改程序增加的源程序語句條數修改程序減少的源程序語句條數每次修改所付出的“人時”數修改程序的日期軟件維護人員的姓名維護申請報告的名稱、維護類型維護開始時間和維護結束時間、花費在維護上的累計“人時”數維護工作的凈收益等。

修改程序增加的源程序語句條數123維護評價評價維護活動比較困難，因為缺乏可靠的數據。如果維護的檔案記錄做得比較好，可以得出一些維護“性能”方面的度量值。每次程序運行時的平均出錯次數；花費在每類維護上的總“人時”數；每個程序、每種語言、每種維護類型的程序平均修改次數；維護評價評價維護活動比較困難，因為缺乏可靠的數據。124因為維護，增加或刪除每個源程序語句所花費的平均“人時”數；用于每種語言的平均“人時”數；維護申請報告的平均處理時間；各類維護申請的百分比。因為維護，增加或刪除每個源程序語句所花費的平均“人時”數；125軟件可維護性許多軟件的維護十分困難，原因在于這些軟件的文檔不全、質量差、開發過程不注意采用好的方法，忽視程序設計風格等。許多維護要求并不是因為程序中出錯而提出的，而是為適應環境變化或需求變化而提出的。為了使得軟件能夠易于維護，必須考慮使軟件具有可維護性。軟件可維護性許多軟件的維護十分困難，原因在于這些軟件的文檔不126

軟件可維護性的定義軟件可維護性是指糾正軟件系統出現的錯誤和缺陷，以及為滿足新的要求進行修改、擴充或壓縮的容易程度。可維護性、可使用性、可靠性是衡量軟件質量的主要質量特性，也是用戶十分關心的幾個方面。軟件的可維護性是軟件開發階段各個時期的關鍵目標。

軟件可維護性的定義軟件可維護性是指糾正軟件系統出現的錯127目前廣泛使用的是用如下的七個特性來衡量程序的可維護性。

可理解性 可使用性 可測試性 可移植性 可修改性 效率 可靠性而且對于不同類型的維護，這七種特性的側重點也不相同。目前廣泛使用的是用如下的七個特性來衡量程序的可維護性。128在各類維護中的側重點

在各類維護中的側重點129這些質量特性通常體現在軟件產品的許多方面;為使每一個質量特性都達到預定的要求，需要在軟件開發的各個階段采取相應的措施加以保證。這些質量要求要滲透到而各開發階段的各個步驟當中。因此，軟件的可維護性是產品投入運行以前各階段面向上述各質量特性要求進行開發的最終結果。這些質量特性通常體現在軟件產品的許多方面;130可維護性的度量人們一直期望對軟件的可維護性做出定量度量，但要做到這一點并不容易。常用的度量一個可維護的程序的七種特性的方法。就是質量檢查表質量測試質量標準可維護性的度量人們一直期望對軟件的可維護性做出定量度量，但要131質量檢查表是用于測試程序中某些質量特性是否存在的一個問題清單。評價者針對檢查表上的每一個問題，依據自己的定性判斷，回答“Yes”或者“No”。質量測試與質量標準則用于定量分析和評價程序的質量。由于許多質量特性是相互抵觸的，要考慮幾種不同的度量標準，相應地去度量不同的質量特性。質量檢查表是用于測試程序中某些質量特性是否存在的一個問題清單1321.可理解性可理解性表明人們通過閱讀源代碼和相關文檔，了解程序功能及其如何運行的容易程度。一個可理解的程序應具備以下一些特性：模塊化，風格一致性，不使用令人捉摸不定或含糊不清的代碼，使用有意義的數據名和過程名，結構化，完整性等。1.可理解性可理解性表明人們通過閱讀源代碼和相關文檔，了解1332.可靠性可靠性表明一個程序按照用戶的要求和設計目標，在給定的一段時間內正確執行的概率。2.可靠性可靠性表明一個程序按照用戶的要求和設計目標，在給134度量可靠性的方法根據程序錯誤統計數字，進行可靠性預測。常用方法是利用一些可靠性模型，根據程序測試時發現并排除的錯誤數預測平均失效間隔時間。

根據程序復雜性，預測軟件可靠性。

用程序復雜性預測可靠性，前提條件是可靠性與復雜性有關。因此可用復雜性預測出錯率。程序復雜性度量標準可用于預測哪些模塊最可能發生錯誤，以及可能出現的錯誤類型。度量可靠性的方法根據程序錯誤統計數字，進行可靠性預測。常1353.可測試性可測試性表明論證程序正確性的容易程度。程序越簡單，證明其正確性就越容易。而且設計合用的測試用例，取決于對程序的全面理解。一個可測試的程序應當是可理解的，可靠的，簡單的。用于可測試性度量的檢查項目如下：程序是否模塊化?結構是否良好?3.可測試性可測試性表明論證程序正確性的容易程度。程序越簡136程序是否可理解?程序是否可靠?程序是否能顯示任意中間結果?程序是否能以清楚的方式描述它的輸出?程序是否能及時地按照要求顯示所有的輸入?程序是否有跟蹤及顯示邏輯控制流程的能力?

程序是否能從檢查點再啟動?程序是否能顯示帶說明的錯誤信息?程序是否可理解?程序是否可靠?1374.可修改性可修改性表明程序容易修改的程度。一個可修改的程序應當是可理解的、通用的、靈活的、簡單的。通用性是指程序適用于各種功能變化而無需修改。靈活性是指能夠容易地對程序進行修改4.可修改性可修改性表明程序容易修改的程度。138測試可修改性的一種定量方法是修改練習。其基本思想是通過做幾個簡單的修改，來評價修改的難度。測試可修改性的一種定量方法是修改練習。其基本思想是通過做幾個1395.可移植性可移植性表明程序轉移到一個新的計算環境的可能性的大小。或者它表明程序可以容易地、有效地在各種各樣的計算環境中運行的容易程度。一個可移植的程序應具有結構良好、靈活、不依賴于某一具體計算機或操作系統的性能。用于可移植性度量的檢查項目如下：5.可移植性可移植性表明程序轉移到一個新的計算環境的可能性140

是否是用高級的獨立于機器的語言來編寫程序?是否使用廣泛使用的標準化的程序設計語言來編寫程序?是否僅使用了這種語言的標準版本和特性?程序中是否使用了標準的普遍使用的庫功能和子程序?程序中是否極少使用或根本不使用操作系統的功能?是否是用高級的獨立于機器的語言來編寫程序?141程序在執行之前是否初始化內存?程序在執行之前是否測定當前的輸入／輸出設備?程序是否把與機器相關的語句分離了出來，集中放在了一些單獨的程序模塊中，并有說明文件?

程序是否結構化?并允許在小一些的計算機上分段(覆蓋)運行?程序中是否避免了依賴于字母數字或特殊字符的內部位表示?程序在執行之前是否初始化內存?1426.效率效率表明一個程序能執行預定功能而又不浪費機器資源的程度。這些機器資源包括內存容量、外存容量、通道容量和執行時間。用于效率度量的檢查項目如下：程序是否模塊化?結構是否良好?是否消除了無用的標號與表達式，以充分發揮編譯器優化作用?6.效率效率表明一個程序能執行預定功能而又不浪費機器資源的143程序的編譯器是否有優化功能?是否把特殊子程序和錯誤處理子程序都歸入了單獨的模塊中?是否以快速的數學運算代替了較慢的數學運算?是否盡可能地使用了整數運算，而不是實數運算?是否在表達式中避免了混合數據類型的使用，消除了不必要的類型轉換?程序的編譯器是否有優化功能?144程序是否避免了非標準的函數或子程序的調用?在幾條分支結構中，是否最有可能為“真”的分支首先得到測試?在復雜的邏輯條件中，是否最有可能為“真“的表達式首先得到測試?程序是否避免了非標準的函數或子程序的調用?1457.可使用性從用戶觀點出發，可使用性定義為程序方便、實用、及易于使用的程度。一個可使用的程序應是易于使用的、能允許用戶出錯和改變，并盡可能不使用戶陷入混亂狀態的程序。用于可使用性度量的檢查項目如下：程序是否具有自描述性?7.可使用性從用戶觀點出發，可使用性定義為程序方便、實用、146

程序是否能始終如一地按照用戶的要求運行?程序是否讓用戶對數據處理有一個滿意的和適當的控制?程序是否容易學會使用?程序是否使用數據管理系統來自動地處理事務性工作和管理格式化、地址分配及存儲器組織。程序是否具有容錯性?程序是否靈活?程序是否能始終如一地按照用戶的要求運行?147其它間接定量度量可維護性的方法問題識別的時間；因管理活動拖延的時間；收集維護工具的時間；分析、診斷問題的時間；修改規格說明的時間；具體的改錯或修改的時間；局部測試的時間；集成或回歸測試的時間；維護的評審時間；其它間接定量度量可維護性的方法問題識別的時間；148這些數據反映了維護全過程中檢錯－糾錯－驗證的周期，即從檢測出軟件存在的問題開始至修正它們并經回歸測試驗證這段時間。可以粗略地認為，這個周期越短，維護越容易。這些數據反映了維護全過程中檢錯－糾錯－驗證的周期，即從檢測出149提高可維護性的方法建立明確的軟件質量目標和優先級使用提高軟件質量的技術和工具進行明確的質量保證審查選擇可維護的程序設計語言改進程序的文檔提高可維護性的方法建立明確的軟件質量目標和優先級150建立明確的軟件質量目標和優先級一個可維護的程序應是可理解的、可靠的、可測試的、可修改的、可移植的、效率高的、可使用的。要實現這所有的目標，需要付出很大的代價，而且也不一定行得通。某些質量特性是相互促進的，例如可理解性和可測試性、可理解性和可修改性。建立明確的軟件質量目標和優先級一個可維護的程序應是可理解的、151

另一些質量特性是相互抵觸的，如效率和可移植性、效率和可修改性等。每一種質量特性的相對重要性應隨程序的用途及計算環境的不同而不同。例如，對編譯程序來說，可能強調效率；但對管理信息系統來說，則可能強調可使用性和可修改性。應當對程序的質量特性，在提出目標的同時還必須規定它們的優先級。

另一些質量特性是相互抵觸的，如效率和可移植性、效率和可修改152使用提高軟件質量的技術和工具模塊化

如果需要改變某個模塊的功能，則只要改變這個模塊，對其它模塊影響很小；如果需要增加程序的某些功能，則僅需增加完成這些功能的新的模塊或模塊層；程序的測試與重復測試比較容易；程序錯誤易于定位和糾正；

使用提高軟件質量的技術和工具模塊化153結構化程序設計程序被劃分成分層的模塊結構；模塊調用控制必須從模塊的入口點進入，從其出口點退出。模塊的控制結構僅限于順序、選擇、重復三種，且沒有GOTO語句。每個程序變量只用于唯一的程序目的，而且變量的作用范圍應是明確的、有限制的。結構化程序設計154

使用結構化程序設計技術，提高現有系統的可維護性采用備用件的方法──用一個新的結構良好的模塊替換掉整個要修改的模塊。采用自動重建結構和重新格式化的工具(結構更新技術)──把非結構化代碼轉換成良好結構代碼。改進現有程序的不完善的文檔──建立或補充系統說明書、設計文檔、模塊說明書、以及在源程序中插入必要的注釋。

使用結構化程序設計技術，提高現有系統的可維護性155進行明確的質量保證審查質量保證審查對于獲得和維持軟件的質量，是一個很有用的技術。審查可以用來檢測在開發和維護階段內發生的質量變化。一旦檢測出問題來，就可以采取措施來糾正，以控制不斷增長的軟件維護成本，延長軟件系統的有效生命期。進行明確的質量保證審查質量保證審查對于獲得和維持軟件的質量，156保證軟件質量的最佳方法是在軟件開發的最初階段把質量要求考慮進去，并在開發過程每一階段的終點，設置檢查點進行檢查。檢查的目的是要證實，已開發的軟件是否符合標準，是否滿足規定的質量需求。在不同的檢查點，檢查的重點不完全相同。1.在檢查點進行復審保證軟件質量的最佳方法