軟件工程課件：軟件維護

軟件維護6.1軟件維護的基本概念6.2軟件維護的任務和分類6.3軟件維護過程6.4維護的管理6.5預防性維護6.6軟件維護的副作用6.7軟件文檔與編寫要求及方法6.8軟件逆向工程和再工程6.9小結習題6

知識點

軟件維護的基本概念，維護管理，維護過程，預防性維護，維護的副作用，軟件文檔，軟件逆向工程和再工程。

難點

軟件維護過程和管理，預防性維護，軟件文檔編寫。

基于工作過程的教學任務

通過本章的學習，了解軟件維護的基本概念及分類，軟件維護的副作用，軟件可維護性對軟件開發(fā)的重要性；掌握預防性維護、軟件文檔編寫要求和方法、軟件維護過程、軟件維護類型、以及提供軟件可維護性的方法；了解軟件逆向工程與再工程的基本過程。

6.1軟件維護的基本概念

軟件工程的目的就是提高軟件的可維護性，減少軟件維護所需要的工作量，降低軟件系統(tǒng)的總成本。所謂軟件維護就是在軟件已經交付使用之后，為了改正錯誤或滿足新的需要而修改軟件的過程?？梢酝ㄟ^描述軟件交付使用后可能進行的4項維護活動，具體地定義軟件維護。這4種維護活動為改正性維護、適應性維護、完善性維護、預防性維護。

軟件維護絕不僅限于糾正使用中發(fā)現(xiàn)的錯誤，事實上在全部維護活動中一半以上是擴充與完善性維護。統(tǒng)計數(shù)字表明，完善性維護占全部維護活動的50%～66%，改正性維護占17%～21%，適應性維護占18%～25%，預防性維護活動只占4%左右。如圖6-1所示。

圖6-1各種維護的比例

需要注意的是，上述4種維護活動都必須應用于整個軟件配置，維護軟件文檔和維護軟件的可執(zhí)行代碼是同樣重要的。

(1)為什么要進行軟件維護？

舉例：大學科研機構里的軟件維護工作恐怕是做得最差的了。幾乎每一批新的研究生都會把畢業(yè)生留下的軟件臭罵一通，然后全部推倒重做。到他畢業(yè)該走時，就輪到別人評論他的工作了。如此輪回，最終沒有什么成果留下。

通過上述案例可以看出，如果希望軟件系統(tǒng)能延長壽命，必須要對它進行維護。如果希望軟件系統(tǒng)有效益，則必須設法降低維護的代價。

(2)影響維護工作量的因素。

①系統(tǒng)大?。合到y(tǒng)越大，理解掌握起來越困難。系統(tǒng)越大，所執(zhí)行功能越復雜。

②程序設計語言：使用強功能的程序設計語言可以控制程序的規(guī)模。語言的功能越強，生成程序的模塊化和結構化程度越高，所需的指令數(shù)就越少，程序的可讀性越好。

③數(shù)據庫技術的應用：使用數(shù)據庫，可以簡單而有效地管理和存儲用戶程序中的數(shù)據，還可以減少生成用戶報表應用軟件的維護工作量。

④先進的軟件開發(fā)技術：在軟件開發(fā)時，若使用能使軟件結構比較穩(wěn)定的分析與設計技術及程序設計技術，如面向對象技術、復用技術等，可減少大量的工作量。

(3)軟件維護的成本。

有形的維護成本是花費了多少錢；無形的維護成本是帶來的負面影響。

6.2軟件維護的任務和分類

軟件維護的主要任務就是在軟件使用或軟件維護階段，為了改正錯誤或滿足新的需要而修改軟件，使軟件能持久地滿足用戶的需求。按軟件維護的不同性質，可以把軟件維護分為改正性維護、適用性維護、完善性維護、預防性維護四種類型。

1．改正性維護

因為軟件測試不可能暴露出一個大型軟件系統(tǒng)中所有潛藏的錯誤，所以必然會有第一項維護活動：在任何大型程序的使用期間，用戶必然會發(fā)現(xiàn)程序錯誤，并且把他們遇到的問題報告給維護人員。因此，把診斷和改正錯誤的過程稱為改正性維護。

2．適用性維護

適用性維護是為了使系統(tǒng)適應環(huán)境的變化而進行的維護工作。一方面，信息系統(tǒng)要能夠適應新的軟硬件環(huán)境，以提高系統(tǒng)的性能和運行效率；另一方面，應用對象在不斷發(fā)生變化，機構的調整，管理體制的改變、數(shù)據與信息需求的變更等都將導致系統(tǒng)不能適應新的應用環(huán)境。如代碼改變、數(shù)據結構變化、數(shù)據格式以及輸入/輸出方式的變化、數(shù)據存儲介質的變化等，都將直接影響系統(tǒng)的正常工作。因此，有必要對系統(tǒng)進行調整，使之適應應用對象的變化，滿足用戶的需求。

3．完善性維護

在系統(tǒng)的使用過程中，用戶往往要求擴充原有系統(tǒng)的功能，增加一些在軟件需求規(guī)范書中沒有規(guī)定的功能與性能特征，以及對處理效率和編寫程序的改進。例如，有時可將幾個小程序合并成一個單一的運行良好的程序，從而提高處理效率；增加數(shù)據輸出的圖形方式；增加聯(lián)機在線幫助功能；調整用戶界面等。盡管這些要求在原有系統(tǒng)開發(fā)的需求規(guī)格說明書中并沒有，但用戶要求在原有系統(tǒng)基礎上進一步改善和提高，并且隨著用戶對系統(tǒng)的使用和熟悉，這種要求可能會不斷提出，為了滿足這些要求就要進行完善性維護工作。

4．預防性維護

為了改進未來的可維護性或可靠性，或為了給未來的改進奠定更好的基礎而修改軟件時，就出現(xiàn)了第4項維護活動。這項維護活動通常稱為預防性維護，目前這項維護活動相對比較少。

軟件維護工作不應總是被動地等待用戶提出要求后才進行，應進行主動的預防性維護，即選擇那些還有較長使用壽命，目前尚能正常運行，但可能將要發(fā)生變化或調整的系統(tǒng)進行維護，目的是通過預防性維護為未來的修改與調整奠定更好的基礎。例如，將目前能應用的報表功能改成通用報表生成功能，以應對今后報表內容和格式可能的變化。

6.3軟件維護過程

維護過程本質上是修改和壓縮了的軟件定義和開發(fā)過程，而且事實上遠在提出一項維護要求之前，與軟件維護有關的工作已經開始了。軟件維護主要包括5個過程：建立維護組織、撰寫維護報告、確定維護事件流、保存維護記錄、評價維護活動。

1．建立維護組織

雖然通常并不需要建立正式的維護組織，但是，即使對于一個小的軟件開發(fā)團體而言，非正式地委托責任也是絕對必要的。每個維護要求都通過維護管理員轉交給相應的系統(tǒng)管理員去評價。系統(tǒng)管理員是被指定去熟悉部分產品程序的技術人員，系統(tǒng)管理員一旦對維護任務做出評價之后，由變化授權人決定應該進行的活動。如圖6-2所示。

在維護活動開始之前就明確維護責任是十分必要的，這樣做可以大大減少維護過程中可能出現(xiàn)的混亂。

圖6-2維護組織

2．撰寫維護報告

應該用標準化的格式表達所有軟件維護要求。軟件維護人員通常給用戶提供空白的維護要求表，有時也稱為軟件問題報告表，這個表格由要求一項維護活動的用戶填寫。如果遇到了一個錯誤，那么必須完整描述導致出現(xiàn)錯誤的環(huán)境(包括輸入數(shù)據、全部輸出數(shù)據以及其他有關信息)。對于適應性或完善性的維護要求，用戶必須提出一份修改說明書，列出所有希望的修改。如前所述，由維護管理員和系統(tǒng)管理員評價用戶提交的維護要求表，并相應做出軟件修改報告，并給出下述信息：

維護要求的性質；

這項要求的優(yōu)先次序；

與修改有關的事后數(shù)據；

滿足維護要求表中提出的要求所需要的工作量。

在擬定進一步的維護計劃之前，把軟件修改報告提交給變化授權人審查批準。

3．確定維護事件流

當一個維護申請?zhí)岢霾⑼ㄟ^評審確定需要維護時，則按圖6-3所描繪的過程實施維護。首先應該確定要求進行的維護的類型。用戶常常把一項要求看作是為了改正軟件的錯誤(改正性維護)，而開發(fā)人員可能把同一項要求看作是適應性或完善性維護。當存在不同意見時，必須協(xié)商解決。

圖6-3維護階段的事件流

從圖6-3描繪的事件流可看到，對一項改正性維護要求(圖中“錯誤”通路)的處理，從估量錯誤的嚴重程度開始。如果是一個嚴重的錯誤(例如，一個關鍵性的系統(tǒng)不能正常運行)，則在系統(tǒng)管理員的指導下分派人員，并且立即開始問題分析過程。如果錯誤并不嚴重，那么改正性的維護和其他要求軟件開發(fā)資源的任務一起統(tǒng)籌安排。

適應性維護和完善性維護的要求沿著相同的事件流通路前進，對每個維護要求進行優(yōu)先度評價，并且安排要求的工作時間，好似它是另一個開發(fā)任務一樣。如果一項維護要求的優(yōu)先次序非常高，就要立即開始維護工作。

不管維護類型如何，都需要進行同樣的技術工作。這些工作包括修改軟件設計、復查、必要的代碼修改、單元測試和集成測試(包括使用以前的測試方案的回歸測試)、驗收測試和復審。不同類型的維護強調的重點不同，但是基本途徑是相同的。維護事件流中最后一個事件是復審，它再次檢驗軟件配置的所有成分的有效性，并且保證事實上滿足了維護要求表中的要求。

4．保存維護記錄

對于軟件生命周期的所有階段而言，以前記錄保存都是不充分的，而軟件維護則根本沒有記錄保存下來。由于這個原因，往往不能估計維護技術的有效性，不能確定一個產品程序的優(yōu)良程度，而且很難確定維護的實際代價是什么。

在維護階段需要記錄一些與維護有關的信息，這些信息可作為估計維護的有效程度，確定軟件產品的質量，估算維護費用等工作的原始依據。維護檔案記錄主要包括：

程序名稱；

源程序語句條數(shù)；

機器代碼指令條數(shù)；

所用的程序設計語言；

程序安裝的日期；

程序安裝后的運行次數(shù)；

與程序安裝后運行次數(shù)有關的處理故障次數(shù)；

程序改變的層次及名稱；

修改程序增加的源程序語句條數(shù)；

修改程序減少的源程序語句條數(shù)；

每次修改所付出的人時數(shù)；

修改程序的日期；

軟件維護人員的姓名；

維護申請報告的名稱、維護類型；

維護開始時間和維護結束時間；

花費在維護上的累計人時數(shù)；

維護工作的凈收益等。

5．評價維護活動

缺乏有效的數(shù)據就無法評價維護活動。如果已經開始保存維護記錄了，則可以對維護工作做一些定量度量。至少可以從下述7個方面度量維護工作：

每次程序運行平均失效的次數(shù)；

用于每一類維護活動的總人時數(shù)；

平均每個程序、每種語言、每種維護類型所做的程序變動數(shù)；

維護過程中增加或刪除一個源語句平均花費的人時數(shù)；

維護每種語言平均花費的人時數(shù)；

一張維護要求表的平均周轉時間；

不同維護類型所占的百分比。

根據對維護工作定量度量的結果，可以做出關于開發(fā)技術、語言選擇、維護工作量規(guī)劃、資源分配及其他許多方面的決定，而且可以利用這些數(shù)據去分析評價維護任務。

6.4維護的管理

軟件維護管理包括有缺陷報告、批準對產品的修改、軟件的可維護性、影響軟件可維護性的因素、軟件可維護性度量、提高軟件可維護性的方法等。

1.缺陷報告

缺陷報告必須包括足夠的信息，使維護程序員能夠再現(xiàn)該問題，通常是某種類型的軟件故障。另外，維護程序員必須指出缺陷的嚴重性，典型的嚴重性類別包括致命的、主要的、通常的、較小的和微不足道的。

理想情況下，用戶提出的每個缺陷都應立即糾正。而實際上，程序開發(fā)公司通常人力不足，開發(fā)和維護工作都會滯后。如果缺陷是致命的，例如工資發(fā)放軟件在發(fā)工資的前一天或有員工增減工資的前一天崩潰了，那么必須立即采取糾正措施。其他情況下，必須立即對每一份缺陷報告進行初步的調查。

維護程序員應該首先參考缺陷報告文件。缺陷報告包括已經發(fā)現(xiàn)但尚未糾正的所有缺陷，以及關于在缺陷得到糾正之前用戶如何繞過它們的建議。如果缺陷以前已經報告過，缺陷報告中的任何信息都應傳遞給用戶。但如果用戶報告的是新缺陷，那么維護程序員應該對問題加以研究并設法找出原因和解決問題。

另外，應該設法找到繞過問題的辦法，因為有可能需要6～9個月的時間才能分配人力對軟件做出必要的修改?？紤]到程序員，特別是能夠勝任維護工作的優(yōu)秀程序員的短缺，對于那些不十分緊急的缺陷報告，只能建議用戶通過某種方法繼續(xù)使用帶有缺陷的軟件，直到缺陷可以得到解決。

然后，維護程序員的結論要連同所有支持其結論的文檔——用以得出上述結論的清單、設計、手冊等，一同加入缺陷報告文件中。負責交付后維護的管理員應該定期閱讀該報告，確定各種糾錯任務的優(yōu)先次序。該文件還應包括客戶在完善性維護和適應性維護等方面的要求，下一次將糾正優(yōu)先級最高的缺陷。

2.批準對產品的修改

一旦決定進行糾錯性維護，維護程序員就要查找軟件運行失敗的原因，并承擔起修正該錯誤的任務。代碼改變后，必須像對整個產品進行測試一樣，對所做修改進行回歸測試。然后必須更新文檔，以反映所做的修改。特別是對改變后的代碼制品，要在其序言注釋中加入關于進行了哪些修改、為什么修改、由誰做的修改以及何時進行修改等方面的信息。如果有必要，分析或設計制品也需要修改。

在完善性維護或適應性維護之后，也要采取類似的步驟。唯一的區(qū)別是，完善性維護和適應性維護是按客戶要求進行的，不是由缺陷報告引發(fā)的。

如果維護程序員對所做的修改測試不充分該怎么辦呢?產品在發(fā)布前，要通過一個獨立的小組進行軟件質量保證，即維護SQA小組的成員一定不能作為維護程序員給相同的管理者提供報告。SQA保持管理上的獨立很重要。

維護工作是容易出錯的，交付后維護期間的測試是困難的，也是消耗時間的。SQA小組不應低估測試對軟件維護的影響，一旦新版本得到SQA小組的批準，它就可以發(fā)布了。

3.軟件的可維護性

許多軟件的維護十分困難，原因在于，這些軟件的文檔不全、質量差、開發(fā)過程不注意采用好的方法，忽視程序設計風格等。許多維護要求并不是因為程序中出錯而提出的，而是為適應環(huán)境變化或需求變化而提出的。為了使得軟件能夠易于維護，必須考慮使軟件具有可維護性。

軟件可維護性是指糾正軟件系統(tǒng)出現(xiàn)的錯誤和缺陷，以及為滿足新的要求進行修改、擴充或壓縮的難易程度。在前面的章節(jié)中曾經多次強調，提高可維護性是支配軟件工程方法學所有步驟的關鍵目標。

4．影響軟件可維護性的因素

維護就是在軟件交付使用后進行的修改，修改之前必須理解待修改的對象，修改之后應該進行必要的測試，以保證所做的修改是正確的。如果是改正性維護，還必須預先進行調試以確定錯誤的具體位置。因此，影響軟件可維護性的因素主要有下述7個：

1)可理解性

軟件可理解性表現(xiàn)為維護人員理解軟件的結構、功能、接口和內部處理過程的難易程度。模塊化(模塊結構良好，高內聚，松耦合)、詳細的設計文檔、結構化設計、程序內部的文檔和良好的高級程序設計語言等，都對提高軟件的可理解性有重要貢獻。

2)可測試性

軟件的可測試性指程序正確性的難易程度。診斷和測試的容易程度取決于軟件容易理解的程度，良好的文檔對診斷和測試是至關重要的。維護人員應該能夠得到在開發(fā)階段用過的測試方案，以便進行回歸測試。

3)可修改性

軟件可修改性指修改程序的難易程度。軟件容易修改的程度和本書第3章講過的結構化設計原理和啟發(fā)規(guī)則直接有關。耦合、內聚、信息隱藏、局部化、控制域與作用域的關系等等，都影響軟件的可修改性。

4)可靠性

軟件可靠性指一個程序在滿足用戶功能需求的基礎上，在一定時間內正確執(zhí)行的概率。軟件的可靠性越好，越有助于減少由于修改軟件而出現(xiàn)更多的錯誤，越有利于維護工作。

5)可移植性

軟件可移植性指把程序從一種計算環(huán)境(硬件配置和操作系統(tǒng))轉移到另一種計算環(huán)境的難易程度。把與硬件、操作系統(tǒng)以及其他外部設備有關的程序代碼集中放到特定的程序模塊中，可以把因環(huán)境變化而必須修改的程序局限在少數(shù)程序模塊中，從而降低修改的難度。

6)可使用性

軟件可使用性是指程序方便、實用及易于使用的程度。一個可使用的程序應是易于使用、允許用戶出錯和改變、并盡可能不使用戶陷入混亂狀態(tài)的程序。

7)效率

效率指一個程序能執(zhí)行預定功能而又不浪費機器資源的程度(即對存儲容量、通道容量和執(zhí)行時間的使用情況)。編程時，不能一味追求效率，有時需要犧牲部分執(zhí)行效率而提高程序的其他特性。

對于不同類型的維護，上述7個因素的側重點也不相同。表6-1列出了在各類維護中應側重哪些特性。

5．軟件可維護性度量

軟件維護性度量的任務是對軟件產品的維護性給出量化的評價，和其他軟件質量特性一樣，軟件維護的度量也分為內部維護性度量和外部維護性度量。

從表6-2中可以看出，內部維護性度量是在軟件產品尚未開發(fā)完成時實施的度量。此時只有階段產品，例如已得到設計規(guī)格說明和源程序(但未經測試)，度量的目的在于預測將獲得的軟件產品的維護性。而外部維護性度量則是在產品完成后，經運行開發(fā)出的程序而獲得的維護性數(shù)據。

維護性度量的實施者可能是用戶、測試人員、開發(fā)人員、產品評價人員或是軟件維護人員。以下分別說明內部維護性子特性度量及外部維護性子特性度量的含義：

(1)內部維護性子特性度量。

易分析性度量—預測未來維護人員或軟件產品用戶在維護工作中為診斷軟件產品缺陷或失效原因，或是找出要修改的部分所付出的工作量和資源。

易變更性度量—預測未來維護人員或軟件產品用戶在進行維護時，修改軟件所需的工作量。

穩(wěn)定性度量—預測對軟件產品進行修改后的穩(wěn)定程度，例如，如果某軟件產品修改的局部化程度較高，或是修改變更的副作用較小，表明未來產品的維護性的穩(wěn)定性較好。

測試性度量—預測軟件產品中設計并實現(xiàn)的自動測試輔助功能的總量。

維護性的依從性度量—評估軟件產品遵循與維護性有關的用戶組織的標準、約定或法規(guī)的能力。例如，如果開發(fā)的軟件是出口給某外國公司的產品，那就要評估該產品是否能符合該國、該公司有關軟件維護性的標準或法規(guī)。

(2)外部維護性子特性度量。

易分析性度量—軟件維護人員或軟件產品用戶在維護工作中為診斷軟件產品缺陷或失效原因，或是找出要修改的部分所付出的工作量和資源。

易變更性度量—軟件維護人員或軟件產品用戶在進行維護時，修改所付出的工作量，如實現(xiàn)變更所用時間。

穩(wěn)定性度量—在軟件產品修改后的測試或運行時對所出現(xiàn)的意外行為屬性的度量，如變更成功比率。

測試性度量—在測試已經修改或未修改的軟件時所付出的測試工作量等測試屬性的度量。

維護性的依從性度量—軟件產品不遵循說要求的與維護性相關的標準、約定或法規(guī)的功能數(shù)和出現(xiàn)依從性問題的數(shù)量。

6．提高軟件可維護性的方法

軟件的可維護性對于延長軟件的生存期具有決定意義，因此必須考慮怎樣才能提高軟件的可維護性。為此，可以從以下5個方面著手。

(1)建立明確的軟件質量目標。

如果要使程序完全滿足可維護性的7種影響軟件可維護性的因素，肯定是很難實現(xiàn)的。實際上，某些因素是相互促進的，如可理解性和可測試性，可理解性和可修改性；某些質量特性是相互抵觸的，如效率和可移植性，效率和可修改性。因此，為保證程序的可維護性，應該在一定程度上滿足可維護的各個因素，但各個因素的重要性又是隨著程序的用途或計算機環(huán)境的不同而改變的。

對編譯程序來說，效率和可移植性是主要的；對信息管理系統(tǒng)來說，可使用性和可修改性可能是主要的。通過實驗證明，強調效率的程序包含的錯誤比強調簡明性的程序所包含的錯誤要高出10倍，所以在提出目標的同時還必須規(guī)定它們的優(yōu)先級，這樣有助于提高軟件的質量。

(2)使用先進的軟件開發(fā)技術和工具。

使用先進的軟件開發(fā)技術是軟件開發(fā)過程中提高軟件質量、降低成本的有效方法之一，也是提高可維護性的有效技術。常用的技術有：模塊化、結構化程序設計、自動重建結構和重新格式化的工具等。

例如，面向對象的軟件開發(fā)方法就是一個常用的強而有力的軟件開發(fā)方法。面向對象方法是按照人的思維方法，用現(xiàn)實世界的概念來思考問題的，這樣能自然地解決問題。它強調模擬現(xiàn)實世界中的概念而不是強調算法，鼓勵開發(fā)者在開發(fā)過程中按應用領域的實際概念來思考并建立模型，模擬客觀世界，使描述問題的問題空間和解空間盡量一致，開發(fā)出盡量直觀、自然地表現(xiàn)求解方法的軟件系統(tǒng)。

總之，面向對象方法開發(fā)出來的軟件系統(tǒng)的穩(wěn)定性好、容易修改、易于測試和調試，因此可維護性好。

(3)建立明確的質量保證工作。

質量保證是提高軟件質量所做的各種檢查工作。在軟件開發(fā)和軟件維護的各階段，質量保證檢查是非常有效的方法。為了保證軟件的可維護性，有4種類型的軟件檢查。

①在檢查點進行復審。

檢查點是軟件開發(fā)過程中一個階段的終點。檢查點進行檢查的目標是，證實已開發(fā)的軟件是滿足設計要求的。保證軟件質量的最佳方法是，在軟件開發(fā)的最初階段就把質量要求考慮進去，并在每個階段的終點，設置檢查點進行檢查。各階段的檢查重點、對象和方法如表6-3所示。

②驗收檢查。

驗收檢查是對一個特殊的檢查點的檢查，它是把軟件從開發(fā)轉移到維護的最后一次檢查。它對減少維護費用，提高軟件質量非常重要。

③周期性的維護檢查。

上述兩種軟件檢查可用來保證新的軟件系統(tǒng)的可維護性。周期性的維護檢查的結果是開發(fā)階段對檢查點進行檢查的繼續(xù)，采用的檢查方法和內容都是相同的。把多次檢查的結果與以前進行的驗收檢查的結果和檢查點檢查的結果進行比較，對檢查結果的任何變化進行分析，并找出原因。

④對軟件包進行檢查。

上述三種方法使用與組織內部開發(fā)和維護的軟件或專為少量用戶設計的軟件，很難適用于有很多用戶的通用軟件包。因軟件包屬于賣方的資產，用戶很難獲得軟件包源代碼和完整的文檔。對軟件包的維護通常采用單位的維護程序員在分析研究賣方提供的用戶手冊、操作手冊、培訓手冊、新版本策略指導、計算機環(huán)境和驗收測試的基礎上，深入了解本單位的希望和要求，來編制軟件包檢驗程序。軟件包檢測程序是一個測試程序，它檢查軟件包程序所執(zhí)行的功能是否與用戶的要求和條件相一致。

(4)選擇可維護的程序設計語言。

程序設計語言的選擇對軟件可維護性影響很大。恰當?shù)某绦蛟O計語言能使編碼時困難最少，可以減少需要的程序測試量，并且可以得到更容易閱讀、更容易維護的程序。

第四代語言(4GL)，例如查詢語言、圖形語言、報表生成語言和非常高級語言等，對減少維護費用來說是最有吸引力的語言。人們容易理解、使用和修改它們。

例如，用戶使用4GL開發(fā)商業(yè)應用程序比使用通常的高級語言快很多倍。一些4GL是過程語言，另一些是非過程語言。對非過程語言，用戶不需要指出實現(xiàn)算法，只需向編譯程序或解釋程序提出自己的要求。例如它能自動選擇報表格式、文字字符類型等。自動生成指令能改進軟件的可靠性。另外，4GL容易理解，容易編程，程序容易修改，因此改進了可維護性。

(5)改進程序的文檔。

程序員利用程序文檔來解釋和理解程序的內部結構，以及程序同系統(tǒng)內其他程序、操作系統(tǒng)和其他軟件系統(tǒng)是如何相互作用的。程序文檔包括源代碼注釋、設計文檔、系統(tǒng)流程、程序流程圖和交叉引用表等。

程序文檔是對程序的總目標、程序的各組成部分之間的關系、程序設計策略、程序時間過程的歷史數(shù)據等的說明和補充。程序文檔能提高程序的可閱讀性。為了維護程序，人們不得不閱讀和理解程序文檔。雖然大家對程序的看法不一，但普遍同意以下觀點：

好的文檔能使程序更容易閱讀，壞的文檔比沒有更糟糕；

好的文檔簡明扼要，風格統(tǒng)一，容易修改；

程序編碼中加入必要的注釋可提高程序的可理解性；

程序越長、越復雜，越應該注意程序文檔的編寫。

6.5預

防

性

維

護

幾乎所有歷史比較悠久的軟件開發(fā)組織，都有一些十幾年前開發(fā)出的老系統(tǒng)。目前，某些老系統(tǒng)仍然在為用戶服務，但是，當初開發(fā)這些程序時并沒有使用軟件工程方法學來指導。因此，這些程序的體系結構和數(shù)據結構都很差，文檔不全甚至完全沒有文檔，對曾經做過的修改也沒有完整的記錄。針對這些壽命長、目前正在為用戶服務的老版本的軟件系統(tǒng)，為了更好地發(fā)揮其優(yōu)勢，需要進行預防性維護。

預防性維護，就是采用先進的軟件工程方法對需要維護的軟件或軟件中的某一部分(重新)進行設計、編制和測試。預防性維護的目的是為了提高軟件的可維護性、可靠性等，為以后進一步改進軟件打下良好基礎。

怎樣滿足用戶對上述這類老系統(tǒng)的維護要求呢？為了修改這類程序以適應用戶新的或變更的需求，有以下幾種做法可供選擇：

(1)盲目修改。反復多次地做修改程序的嘗試，與不可見的設計及源代碼“頑強戰(zhàn)斗”，以實現(xiàn)所要求的修改。

(2)認真閱讀。通過仔細分析程序，盡可能多地掌握程序的內部工作細節(jié)，以便更有效地修改它。

(3)重新設計。在深入理解原有設計的基礎上，用軟件工程方法重新設計、重新編碼和測試那些需要變更的軟件部分。

(4)借助先進工具。以軟件工程方法學為指導，對程序全部重新設計、重新編碼和測試，為此可以使用CASE工具(逆向工程和再工程工具)來幫助理解原有的設計。

第一種做法很盲目，通常人們采用后3種做法。其中第4種做法稱為軟件再工程，而第3種做法實質上是局部的再工程。

預防性維護方法是由米勒(Miller)提出來的，他的想法是“結構化翻新”，并將這個概念定義為：把今天的方法學應用到昨天的系統(tǒng)上，以支持明天的需求。

粗看起來，在一個正在工作的程序版本已經存在的情況下，重新開發(fā)一個大型程序，似乎是一種浪費。其實不然，下述事實很能說明問題。

(1)維護一行源代碼的代價可能是最初開發(fā)該行源代碼代價的14～40倍；

(2)重新設計軟件體系結構(程序及數(shù)據結構)時使用了現(xiàn)代設計概念，它對將來的維護可能有很大的幫助；

(3)由于現(xiàn)有的程序版本可作為軟件原型使用，開發(fā)生產率可大大高于平均水平；

(4)用戶具有較多使用該軟件的經驗，因此，能夠很容易地搞清新的變更需求和變更的范圍；

(5)利用逆向工程和再工程的工具，可以使一部分工作自動化；

(6)在完成預防性維護的過程中可以建立起完整的軟件配置。

雖然由于條件所限，目前預防性維護在全部維護活動中僅占很小比例，但是，我們不應該忽視這類維護，在條件具備時應該主動地進行預防性維護。

6.6軟件維護的副作用

通過維護可以延長軟件的壽命，使其創(chuàng)造更多的價值。但是，修改軟件是危險的，每修改一次，可能會產生新的潛在錯誤。因此，維護的副作用是指由于修改程序而導致新的錯誤或新增加一些不必要的活動。一般，軟件維護產生的副作用有如下3種。

1．修改代碼的副作用

在使用程序設計語言修改源代碼時，可能引入新的錯誤。例如修改或刪除一個標識符、改變占用存儲的大小、改進程序的執(zhí)行效率、改變邏輯運算符，以及把設計上的改變翻譯成代碼的改變、邊界條件的邏輯測試做出改變等。任何一個修改都容易引入錯誤，因此在修改時必須特別小心。

2．修改數(shù)據的副作用

在修改數(shù)據結構時，有可能造成軟件設計與數(shù)據結構不匹配，因而導致軟件出錯。例如在重新定義局部常量或全局常量、修改全局數(shù)據或公共數(shù)據、重新初始化控制標志或指針、減小或增大一個數(shù)組大小、減小或增大一個高層數(shù)據結構大小、重新排列輸入或輸出的參數(shù)時，非常容易導致設計與數(shù)據不相容的錯誤。修改數(shù)據的副作用是修改軟件信息結構導致的，它可以通過詳細的設計文檔來加以控制。在文檔中通過一種交叉引用，把數(shù)據元素、記錄、文件和其他結構聯(lián)系起來。

3．修改文檔的副作用

對數(shù)據流、軟件結構、模塊邏輯或任何其他有關特性進行修改時，必須對相關技術文檔進行相應修改。但修改文檔過程會產生新的錯誤，導致文檔與程序功能不匹配、缺省條件改變、新錯誤信息不正確等，產生修改文檔的副作用。例如對交互輸入的順序或格式進行修改，如果沒有正確地記入文檔中，可能引起重大的問題。因此，必須在軟件交付前對整個軟件配置進行評審，以減少文檔的副作用。

為了控制因修改而引起的副作用，要做到以下幾點：

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

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

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

(4)對每個修改過的模塊，在安排修改下一個模塊之前，要確定這個修改的副作用。

6.7軟件文檔與編寫要求及方法

文檔(document)是指某些數(shù)據媒體和其中所記錄的數(shù)據。文檔具有永久性，并可以由人或機器閱讀。在軟件工程中文檔常常用來表示對活動、需求、過程或結果進行描述、定義、規(guī)定、報告或認證的任何書面或圖示的信息。文檔也是軟件產品的一部分，沒有文檔的軟件就不稱其為軟件。軟件文檔的編制在軟件開發(fā)中占有突出的地位和相當大的工作量。高質量、高效率地開發(fā)、管理和維護文檔，對于轉讓、變更、修正、擴充和使用文檔，對于充分發(fā)揮軟件產品的效益有著重要的意義。

舉例：一位軟件公司的老總感慨地說：“做軟件公司，最痛苦的事情是下班之后，你發(fā)現(xiàn)自己的公司除了幾臺電腦外，幾乎什么也沒有了?！币驗楣咀钪靛X的資產都在每個程序員的腦子里，這些人一旦離開，公司的資產就等于零。

6.7.1軟件文檔的重要性與分類

文檔是影響軟件可維護性的決定因素。由于長期使用的大型軟件系統(tǒng)在使用過程中必然會經受多次修改，所以維護期間的文檔比程序代碼更重要。例如國內某著名IT企業(yè)所提到的“人人都痛恨別人不寫文檔，人人自己都不愿意寫文檔”，說明軟件文檔十分重要。

軟件系統(tǒng)的文檔可以分為用戶文檔和系統(tǒng)文檔兩類。用戶文檔主要描述系統(tǒng)功能和使用方法，并不關心這些功能是怎樣實現(xiàn)的；系統(tǒng)文檔描述系統(tǒng)設計、實現(xiàn)和測試等各方面的內容。文檔在開發(fā)人員、維護人員、管理人員、用戶與計算機之間起著重要的橋梁作用，如圖6-4所示。

軟件開發(fā)人員在各個階段中以文檔作為前階段工作成果的體現(xiàn)和后階段工作的依據。軟件開發(fā)過程中軟件開發(fā)人員需制定一些工作計劃或工作報告，這些計劃和報告都要提供給管理人員，并得到必要的支持。管理人員則可通過這些文檔了解軟件開發(fā)項目安排、進度、資源使用和成果等。軟件開發(fā)人員需為用戶了解軟件的使用、操作和維護提供詳細的資料。文檔作為計算機軟件的重要組成部分，告訴用戶如何操作和維護系統(tǒng)。

圖6-4文檔的橋梁作用

下面分別討論用戶文檔和系統(tǒng)文檔。

1．用戶文檔

用戶文檔是用戶了解系統(tǒng)的第一步，它應該能使用戶獲得對系統(tǒng)的準確的初步印象。文檔的結構方式應該使用戶能夠方便地根據需要閱讀有關的內容。用戶文檔至少應該包括下述5方面的內容。

(1)功能描述：說明系統(tǒng)能做什么。

(2)安裝文檔：說明怎樣安裝這個系統(tǒng)以及怎樣使系統(tǒng)適應特定的硬件配置。

(3)使用手冊：圖表結合、文字前后描述統(tǒng)一，簡要說明如何著手使用這個系統(tǒng)(應該通過豐富例子說明怎樣使用常用的系統(tǒng)功能，還應該說明用戶操作錯誤時怎樣恢復和重新啟動)。

(4)參考手冊：詳盡描述用戶可以使用的所有系統(tǒng)設施以及它們的使用方法，還應該解釋系統(tǒng)可能產生的各種出錯信息的含義(對參考手冊最主要的要求是完整，因此通常使用形式化的描述技術)。

(5)操作員指南(如果需要有系統(tǒng)操作員的話)：說明操作員應該如何處理使用中出現(xiàn)的各種情況。

上述內容可以分別作為獨立的文檔，也可以作為一個文檔的不同分冊，具體做法應該由系統(tǒng)規(guī)模決定。

2．系統(tǒng)文檔

系統(tǒng)文檔又稱開發(fā)文檔，指從問題定義、需求說明到驗收測試計劃這樣一系列和系統(tǒng)實現(xiàn)有關的文檔。描述系統(tǒng)設計、實現(xiàn)和測試的文檔對于理解程序和維護程序來說是極端重要的。和用戶文檔類似，系統(tǒng)文檔的結構也應該能把讀者從對系統(tǒng)概貌的了解，引導到對系統(tǒng)每個方面每個特點的更形式化更具體的認識。下面通過表6-4顯示出軟件生存期各階段與各種文檔編制的關系。

文檔最終要向軟件管理部門，或向用戶回答下列問題：①What：工作目標要滿足哪些需求？②Where：開發(fā)的軟件在什么環(huán)境中實現(xiàn)，所需信息從哪里來？③When：開發(fā)工作的時間如何安排？④Who：開發(fā)或維護工作打算由誰來完成？⑤How：需求應如何實現(xiàn)？⑥Why：為什么要進行這些軟件開發(fā)或維護修改工作？

6.7.2軟件文檔應該滿足的要求

總的說來，軟件文檔應該滿足下述要求：

必須描述如何使用這個系統(tǒng)，沒有這種描述時即使是最簡單的系統(tǒng)也無法使用；

必須描述怎樣安裝和管理這個系統(tǒng)；

必須描述系統(tǒng)需求和設計；

必須描述系統(tǒng)的實現(xiàn)和測試，以便使系統(tǒng)成為可維護的。

在項目開發(fā)過程中，應該按要求編寫好11種文檔，文檔編制要求具有針對性、精確性、清晰性、完整性、靈活性、可追溯性。

(1)可行性分析報告。說明該軟件開發(fā)項目的實現(xiàn)在技術上、經濟上和社會因素上的可行性，評述為了合理地達到開發(fā)目標可供選擇的各種可能實施方案，說明并論證所選定實施方案的理由。

(2)項目開發(fā)計劃。為軟件項目實施方案制訂出具體計劃，應該包括各部分工作的負責人員、開發(fā)的進度、開發(fā)經費的預算、所需的硬件及軟件資源等。

(3)軟件需求說明書(軟件規(guī)格說明書)。對所開發(fā)軟件的功能、性能、用戶界面及運行環(huán)境等做出詳細的說明。它是在用戶與開發(fā)人員雙方對軟件需求取得共同理解并達成協(xié)議的條件下編寫的，也是實施開發(fā)工作的基礎。該說明書應給出數(shù)據邏輯和數(shù)據采集的各項要求，為生成和維護系統(tǒng)數(shù)據文件做好準備。

(4)概要設計說明書。該說明書是概要實際階段的工作成果，它應說明功能分配、模塊劃分、程序的總體結構、輸入/輸出以及接口設計、運行設計、數(shù)據結構設計和出錯處理設計等，為詳細設計提供基礎。

(5)詳細設計說明書。著重描述每一模塊是怎樣實現(xiàn)的，包括實現(xiàn)算法、邏輯流程等。

(6)用戶操作手冊。本手冊詳細描述軟件的功能、性能和用戶界面，使用戶對如何使用該軟件得到具體的了解，為操作人員提供該軟件各種運行情況的有關知識，特別是操作方法的具體細節(jié)。

(7)測試計劃。為做好集成測試和驗收測試，需為如何組織測試制訂實施計劃。計劃應包括測試的內容、進度、條件、人員、測試用例的選取原則、測試結果允許的偏差范

圍等。

(8)測試分析報告。測試工作完成以后，應提交測試計劃執(zhí)行情況的說明，對測試結果加以分析，并提出測試的結論意見。

(9)開發(fā)進度月報。該月報系軟件人員按月向管理部門提交的項目進展情況報告，報告應包括進度計劃與實際執(zhí)行情況的比較、階段成果、遇到的問題和解決的辦法以及下個月的打算等。

(10)項目開發(fā)總結報告。軟件項目開發(fā)完成以后，應與項目實施計劃對照，總結實際執(zhí)行的情況，如進度、成果、資源利用、成本和投入的人力，此外，還需對開發(fā)工作做出評價，總結出經驗和教訓。

(11)軟件維護手冊。主要包括軟件系統(tǒng)說明、程序模塊說明、操作環(huán)境、支持軟件的說明、維護過程的說明，便于軟件的維護。

6.7.3對軟件文檔編制的質量要求

為了使軟件文檔能起到多種橋梁作用，使它有助于程序員編制程序，有助于管理人員監(jiān)督和管理軟件開發(fā)，有助于用戶了解軟件的工作和應做的操作，有助于維護人員進行有效的修改和擴充，文檔的編制必須保證一定的質量。

質量差的軟件文檔不僅使讀者難于理解，給使用者造成許多不便，而且會削弱對軟件的管理(如管理人員難以確認和評價開發(fā)工作的進展)，增加軟件的成本(如一些工作可能被迫返工)，甚至造成更加有害的后果(如誤操作等)。造成軟件文檔質量不高的原因可能是：缺乏實踐經驗，缺乏評價文檔質量的標準；不重視文檔編寫工作或是對文檔編寫工作的安排不恰當。

高質量的文檔應當體現(xiàn)在以下幾個方面。

(1)針對性：文檔編制以前應分清讀者對象，按不同的類型、不同層次的讀者，決定怎樣適應他們的需要。例如，管理文檔主要是面向管理人員的，用戶文檔主要是面向用戶的，這兩類文檔不應像開發(fā)文檔(面向軟件開發(fā)人員)那樣過多地使用軟件的專業(yè)術語。

(2)精確性：文檔的行文應當十分確切，不能出現(xiàn)多義性的描述。同一課題若干文檔內容應該協(xié)調一致，應是沒有矛盾的。

(3)清晰性：文檔編寫應力求簡明，如有可能，配以適當?shù)膱D表，以增強其清晰性。

(4)完整性：任何一個文檔都應當是完整的、獨立的，它應自成體系。例如，前言部分應作一般性介紹，正文給出中心內容，必要時還有附錄，列出參考資料等。同一課題的幾個文檔之間可能有些部分相同，這些重復是必要的。例如同一項目的用戶手冊和操作手冊中關于本項目功能、性能、實現(xiàn)環(huán)境等方面的描述是沒有差別的。特別要避免在文檔中出現(xiàn)轉引其他文檔內容的情況。例如一些段落并未具體描述，而用“見××文檔××節(jié)”的方式，這將給讀者帶來許多不便。

(5)靈活性：各個不同的軟件項目，其規(guī)模和復雜程度有許多實際差別，不能同等對待。對于較小或較簡單的項目，可做適當調整或合并。例如可將用戶手冊和操作手冊合并成用戶操作手冊；軟件需求說明書可包括對數(shù)據的要求，從而去掉數(shù)據要求說明書；概要設計說明書與詳細設計說明書合并成軟件設計說明書等。

(6)可追溯性：由于各開發(fā)階段編制的文檔與各階段完成的工作有著緊密的關系，前后兩個階段生成的文檔，隨著開發(fā)工作的逐步擴展，具有一定的繼承關系。在一個項目各開發(fā)階段之間提供文檔必定存在著可追溯的關系。例如某一項軟件需求，必定在設計說明書、測試計劃以至用戶手冊中有所體現(xiàn)。必要時應能做到跟蹤追查。

6.7.4軟件文檔的管理和維護

在整個軟件生存期中，各種文檔作為半成品或是最終成品，會不斷地被生成、修改或補充。為了最終得到高質量的產品，達到上節(jié)提出的質量要求，必須加強對文檔的管理。以下幾個方面是應注意做到的：

(1)軟件開發(fā)小組應設一位文檔保管人員，負責集中保管本項目已有文檔的兩套主文本。兩套文本內容完全一致。其中的一套可按一定手續(xù)，辦理借閱。

(2)軟件開發(fā)小組的成員可根據工作需要在自己手中保存一些個人文檔。這些一般都應是主文本的復制件，注意和主文本保持一致，在做必要的修改時，也應先修改主文本。

(3)開發(fā)人員個人只保存著主文本中與他工作相關的部分文檔。

(4)在新文檔取代了舊文檔時，管理人員應及時注銷舊文檔。在文檔內容有更改時，管理人員應隨時修訂主文本，使其及時反映更新了的內容。

(5)項目開發(fā)結束時，文檔管理人員應收回開發(fā)人員的個人文檔。發(fā)現(xiàn)個人文檔與主文本有差別時，應立即著手解決，這常常是未及時修訂主文本造成的。

(6)在軟件開發(fā)過程中，可能發(fā)現(xiàn)需要修改已完成的文檔，特別是規(guī)模較大的項目，主文本的修改必須特別謹慎。修改以前要充分估計修改可能帶來的影響，并且要按照提議、評議、審核、批準和實施等步驟加以嚴格的控制。

軟件文檔作為一類配置項，必須納入配置管理的范圍。在整個軟件生命周期中，通過軟件配置管理，控制這些配置項的投放和更改，記錄并報告配置的狀態(tài)和更改要求，驗證配置項的安全性和正確性以及系統(tǒng)級上的一致性。上面所提到的文檔保管員，可能就是軟件配置管理員，可通過軟件配置信息數(shù)據庫，對配置項(主要是文檔)進行跟蹤和控制。

6.8軟件逆向工程和再工程

所謂軟件再工程(Reengineering)，是以軟件工程學為指導，對老系統(tǒng)進行重新設計、用更先進的程序設計語言重新編碼、執(zhí)行新的測試過程、修改和更新系統(tǒng)結構和系統(tǒng)數(shù)據、重新建立其文檔等方法，來提高老系統(tǒng)的可維護性。就是說，將新技術和新工具應用于老系統(tǒng)的一種較徹底的預防性維護。

軟件再工程作為一種新的預防性維護方法，近年來得到很大發(fā)展。它通過逆向工程和軟件重構等技術，有效地提高現(xiàn)有軟件的可理解性、可維護性和復用性。

典型的軟件再工程過程模型如圖6-5所示，該模型定義了6類活動。一般情況下，這些活動是順序發(fā)生的，但每個活動都可能重復，形成一個循環(huán)的過程，這個過程可以在任意一個活動之后結束。下面簡要地介紹該模型所定義的6類活動。

圖6-5軟件再工程過程模型

1.庫存目錄分析

每個軟件組織都應該保存其擁有的所有應用系統(tǒng)的庫存目錄。該目錄包含關于每個應用系統(tǒng)的基本信息，例如最初構建時間、以往維護情況、訪問的數(shù)據庫、接口情況、文檔數(shù)量與質量、代碼復雜性等。在確定對一個軟件實施再工程之前，應收集這些數(shù)據，根據業(yè)務重要程度、壽命、當前可維護情況等對應用軟件進行分析，從中選出再工程的修造者，合理地分配再工程所需要的資源。

2.文檔重構

文檔重構就是重新構建原本缺乏文檔的應用系統(tǒng)的文檔。根據應用系統(tǒng)的重要性和復雜性，可以選擇對文檔全部重構或維持現(xiàn)狀。

老系統(tǒng)固有的特點是缺乏文檔。具體情況不同，處理這個問題的方法也不同：

(1)建立文檔非常耗費時間，不可能為數(shù)百個程序都重新建立文檔。如果一個程序是相對穩(wěn)定的，正在走向其有用生命的終點，而且可能不會再經歷什么變化，那么，讓它保持現(xiàn)狀是一個明智的選擇。

(2)為了便于今后的維護，必須更新文檔，但是由于資源有限，應采用“使用時建文檔”的方法，也就是說，不是一下子把某應用系統(tǒng)的文檔全部都重建起來，而是只針對系統(tǒng)中當前正在修改的那些部分建立完整文檔。隨著時間流逝，將得到一組有用的和相關的文檔。

(3)如果某應用系統(tǒng)是完成業(yè)務工作的關鍵，而且必須