在軟件產品被開發出來并交付用戶使用之后，就進入了軟件的運行維護階段。這個階段是軟件生命周期的最后一個階段，其基本任務是保證軟件在一個相當長的時期能夠正常運行。

軟件維護需要的工作量很大，平均說來，大型軟件的維護成本高達開發成本的4倍左右。

軟件工程的主要目的就是要提高軟件的可維護性，減少軟件維護所需要的工作量，降低軟件系統的總成本。

1，軟件維護的定義

所謂軟件維護就是在軟件已經交付使用之后，為了改正錯誤或滿足新的需要而修改軟件的過程。可以通過描述軟件交付使用后可能進行的4項活動，具體地定義軟件維護。

改正性維護 （第一項維護活動）	在任何大型程序的使用期間，用戶必然會發現程序錯誤，并且把他們遇到的問題報告給維護人員。把診斷和改正錯誤的過程稱為改正性維護。
適應性維護 （第二項維護活動）	為了和變化了的環境適當地配合而進行的修改軟件的活動，是既必要又經常的維護活動。
完善性維護 （第三項維護活動）	使用軟件的過程中用戶往往提出增加新功能或修改已有功能的建議，還可能提出一般性的改進意見。為了滿足這類要求，需要進行完善性維護。這項維護活動通常占軟件維護工作的大部分。
預防性維護 （第四項維護活動）	為了改進未來的可維護性或可靠性，或為了給未來的改進奠定更好的基礎而修改軟件

從上述關于軟件維護的定義不難看出，軟件維護絕不僅限于糾正使用中發現的錯誤，事實上在全部維護活動中一半以上是完善性維護。應該注意，上述4類維護活動都必須應用于整個軟件配置，維護軟件文檔和維護軟件的可執行代碼是同樣重要的。

2，軟件維護的特點

2.1，結構化維護和非結構化維護的差別很大

1，非機構化維護

如果軟件配置的唯一成分是程序代碼，那么維護活動從艱苦地評價程序代碼開始，而且常常由于程序內部文檔不足而使評價更困難，對于軟件結構、全程數據結構、系統接口、性能和(或)設計約束等經常會產生誤解，而且對程序代碼所做的改動的后果也是難于估量的。

非結構化維護需要付出很大代價(浪費精力并且遭受挫折的打擊)，這種維護方式是沒有使用良好定義的方法學開發出來的軟件的必然結果。

2，結構化維護

如果有一個完整的軟件配置存在，那么維護工作從評價設計文檔開始，確定軟件重要的結構、性能以及接口等特點；估量要求的改動將帶來的影響，并且計劃實施途徑。然后：

• 首先，修改設計并且對所做的修改進行仔細復查。
• 然后，編寫相應的源程序代碼；
• 接下來，使用在測試說明書中包含的信息進行回歸測試；
• 最后，把修改后的軟件再次交付使用。

剛才描述的事件構成結構化維護，它是在軟件開發的早期應用軟件工程方法學的結果。雖然有了軟件的完整配置并不能保證維護中沒有問題，但是確實能減少精力的浪費并且能提高維護的總體質量。

2.2，維護的代價高昂

因為可用的資源必須供維護任務使用，以致耽誤甚至喪失了開發的良機，這是軟件維護的一個無形的代價。其他無形的代價還有以下幾個。

• 當看來合理的有關改錯或修改的要求不能及時滿足時將引起用戶不滿。
• 由于維護時的改動，在軟件中引入了潛伏的錯誤，從而降低了軟件的質量。
• 當必須把軟件工程師調去從事維護工作時，將在開發過程中造成混亂。

軟件維護的最后一個代價是生產率的大幅度下降，這種情況在維護舊程序時常常遇到。

2.3，維護的問題很多

（1）理解別人寫的程序通常非常困難，而且困難程度隨著軟件配置成分的減少而迅速增加。如果僅有程序代碼沒有說明文檔，則會出現嚴重的問題。

（2）需要維護的軟件往往沒有合格的文檔，或者文檔資料顯著不足。認識到軟件必須有文檔僅僅是第一步，容易理解的并且和程序代碼完全一致的文檔才真正有價值。

（3）當要求對軟件進行維護時，不能指望由開發人員給人們仔細說明軟件。由于維護階段持續的時間很長，因此，當需要解釋軟件時，往往原來寫程序的人已經不在附近了。

（4）絕大多數軟件在設計時沒有考慮將來的修改。除非使用強調模塊獨立原理的設計方法學，否則修改軟件既困難又容易發生差錯。

（5）軟件維護不是一項吸引人的工作。形成這種觀念很大程度上是因為維護工作經常遭受挫折。

上述種種問題在現有的沒采用軟件工程思想開發出來的軟件中，都或多或少地存在著。不應該把一種科學的方法學看做萬應靈藥，但是，軟件工程至少部分地解決了與維護有關的每一個問題。

3，軟件維護過程

維護過程本質上是修改和壓縮了的軟件定義和開發過程，而且事實上遠在提出一項維護要求之前，與軟件維護有關的工作已經開始了。

• 首先必須建立一個維護組織
• 隨后必須確定報告和評價的過程
• 而且必須為每個維護要求規定一個標準化的事件序列

此外，還應該建立一個適用于維護活動的記錄保管過程，并且規定復審標準。

3.1，維護組織

雖然通常并不需要建立正式的維護組織，但是，即使對于一個小的軟件開發團體而言，非正式地委托責任也是絕對必要的。

每個維護要求都通過維護管理員轉交給熟悉該產品的系統管理員去評價。系統管理員是被指定去熟悉一小部分產品程序的技術人員。系統管理員對維護任務做出評價之后，由變化授權人決定應該進行的活動。

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

3.2，維護報告

應該用標準化的格式表達所有軟件維護要求。

對于適應性或完善性的維護要求，應該提出一個簡短的需求說明書。如前所述，由維護管理員和系統管理員評價用戶提交的維護要求表。

維護要求表是一個外部產生的文件，它是計劃維護活動的基礎。軟件組織內部應該制定出一個軟件修改報告，它給出下述信息。(1) 滿足維護要求表中提出的要求所需要的工作量。(2) 維護要求的性質。(3) 這項要求的優先次序。(4) 與修改有關的事后數據。

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

3.3，維護的事件流

首先應該確定要求進行的維護的類型。用戶常常把一項要求看作是為了改正軟件的錯誤(改正性維護)，而開發人員可能把同一項要求看作是適應性或完善性維護。當存在不同意見時必須協商解決。

不管維護類型如何，都需要進行同樣的技術工作。包括：修改軟件設計、復查、必要的代碼修改、單元測試和集成測試(包括使用以前的測試方案的回歸測試)、驗收測試和復審。

不同類型的維護強調的重點不同，但是基本途徑是相同的。維護事件流中最后一個事件是復審，它再次檢驗軟件配置的所有成分的有效性，并且保證事實上滿足了維護要求表中的要求。

3.4，保護維護記錄

哪些數據是值得記錄的？

1程序標識；2源語句數；3機器指令條數；4使用的程序設計語言；5程序安裝的日期；6自從安裝以來程序運行的次數；7自從安裝以來程序失效的次數；8程序變動的層次和標識；9因程序變動而增加的源語句數；10因程序變動而刪除的源語句數；11每個改動耗費的人時數；12程序改動的日期；13軟件工程師的名字；14維護要求表的標識；15維護類型；16維護開始和完成的日期；17累計用于維護的人時數；18與完成的維護相聯系的純效益。

應該為每項維護工作都收集上述數據。可以利用這些數據構成一個維護數據庫的基礎。

3.5，評價維護活動

可以從下述7個方面度量維護工作。

• 每次程序運行平均失效的次數。
• 用于每一類維護活動的總人時數。
• 平均每個程序、每種語言、每種維護類型所做的程序變動數。
• 維護過程中增加或刪除一個源語句平均花費的人時數。
• 維護每種語言平均花費的人時數。
• 一張維護要求表的平均周轉時間。
• 不同維護類型所占的百分比。

4，軟件的可維護性

可維護性：維護人員理解、改正、改動或改進這個軟件的難易程度。

提高可維護性是支配軟件工程方法學所有步驟的關鍵目標！

4.1，決定軟件可維護性的因素

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

可理解性	外來讀者理解軟件的結構、功能、接口和內部處理過程的難易程度。
	模塊化（模塊結構良好，高內聚，松耦合）、詳細的設計文檔、結構化設計、程序內部的文檔和良好的高級程序設計語言等，都對提高軟件的可理解性有重要貢獻。
可測試性	診斷和測試的容易程度取決于軟件容易理解的程度。
	對于程序模塊來說，可以用程序復雜度來度量它的可測試性。模塊的環形復雜度越大，可執行的路徑就越多，因此，全面測試它的難度就越高。
可修改性	軟件容易修改的程度和設計原理和啟發規則直接有關。
	耦合、內聚、信息隱藏、局部化、控制域與作用域的關系等，都影響軟件的可修改性。
可移植性	把程序從一種計算環境（硬件配置和操作系統）轉移到另一種計算環境的難易程度。
	把與硬件、操作系統以及其他外部設備有關的程序代碼集中放到特定的程序模塊中，可以把因環境變化而必須修改的程序局限在少數程序模塊中，從而降低修改的難度。
可重用性	同一事物不做修改或稍加改動就在不同環境中多次重復使用。大量使用可重用的軟件構件來開發軟件，可以從下述兩個方面提高軟件的可維護性。
	(1) 通常，可重用的軟件構件在開發時都經過很嚴格的測試，可靠性比較高，且在每次重用過程中都會發現并清除一些錯誤，隨著時間推移，這樣的構件將變成實質上無錯誤的。因此，軟件中使用的可重用構件越多，軟件的可靠性越高，改正性維護需求就越少。
	(2) 很容易修改可重用的軟件構件使之再次應用在新環境中，因此，軟件中使用的可重用構件越多，適應性和完善性維護也就越容易。

4.2，文檔

文檔是影響軟件可維護性的決定因素。由于長期使用的大型軟件系統在使用過程中必然會經受多次修改，所以文檔比程序代碼更重要。

軟件文檔應該滿足下述要求：

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

(2) 必須描述怎樣安裝和管理這個系統。

(3) 必須描述系統需求和設計。

(4) 必須描述系統的實現和測試，以便使系統成為可維護的。

1，用戶文檔

用戶文檔是用戶了解系統的第一步，它應該能使用戶獲得對系統的準確的初步印象。

?(1)功能描述

?(2) 安裝文檔

?(3) 使用手冊

?(4) 參考手冊（要完整）

?(5) 操作員指南(如果需要有系統操作員的話)

2，系統文檔

???????? 所謂系統文檔指從問題定義、需求說明到驗收測試計劃這樣一系列和系統實現有關的文檔。描述系統設計、實現和測試的文檔對于理解程序和維護程序來說是極端重要的。

?????? 和用戶文檔類似，系統文檔的結構也應該能把讀者從對系統概貌的了解，引導到對系統每個方面每個特點的更形式化更具體的認識。

4.3，可維護性復審

為什么要進行可維護性復審？

• 在完成了每項維護工作之后，都應該對軟件維護本身進行仔細認真的復審。
• 不能準確反映軟件當前狀態的設計文檔可能比完全沒有文檔更壞。
• 如果對軟件的可執行部分的修改沒有及時反映在用戶文檔中，則必然會使用戶因為受挫折而產生不滿。
• 在軟件再次交付使用之前，對軟件配置進行嚴格的復審，則可大大減少文檔的問題。
• 在需求分析階段的復審過程中，應該對將來要改進的部分和可能會修改的部分加以注意并指明；應該討論軟件的可移植性問題，并且考慮可能影響軟件維護的系統界面。
• 在正式的和非正式的設計復審期間，應該從容易修改、模塊化和功能獨立的目標出發，評價軟件的結構和過程；設計中應該對將來可能修改的部分預作準備。

5，預防性維護

怎樣滿足用戶對老程序的維護要求？

（1）反復多次地做修改程序的嘗試，與不可見的設計及源代碼“頑強戰斗”，以實現所要求的修改。

（2） 通過仔細分析程序盡可能多地掌握程序的內部工作細節，以便更有效地修改它。

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

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

預防性維護：把今天的方法學應用到昨天的系統上，以支持明天的需求。

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

? (1) 維護一行源代碼的代價可能是最初開發該行源代碼代價的14~40倍。

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

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

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

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

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

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

6，軟件再工程過程

典型的軟件再工程過程模型如下圖所示。在某些情況下這些活動以線性順序發生，但也并非總是這樣。例如，為了理解某個程序的內部工作原理，可能在文檔重構開始之前必須先進行逆向工程。

1，庫存目錄分析

?????? 每個軟件組織都應該保存其擁有的所有應用系統的庫存目錄。該目錄包含關于每個應用系統的基本信息（例如應用系統的名字，最初構建它的日期，已做過的實質性修改次數，過去18個月報告的錯誤，用戶數量，安裝它的機器數量，它的復雜程度，文檔質量，整體可維護性等級，預期壽命，在未來36個月內的預期修改次數，業務重要程度等）。

?????? 應該仔細分析庫存目錄，按照業務重要程度、壽命、當前可維護性、預期的修改次數等標準，把庫中的應用系統排序，從中選出再工程的候選者，然后明智地分配再工程所需要的資源。

2，文檔重構

老程序固有的特點是缺乏文檔。具體情況不同，處理這個問題的方法也不同。

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

(2) 為了便于今后的維護，必須更新文檔，但是由于資源有限，應采用“使用時建文檔”的方法。

(3) 如果某應用系統是完成業務工作的關鍵，而且必須重構全部文檔，則仍然應該設法把文檔工作減少到必需的最小量。

3，逆向工程

軟件的逆向工程是分析程序以便在比源代碼更高的抽象層次上創建出程序的某種表示的過程，也就是說，逆向工程是一個恢復設計結果的過程，逆向工程工具從現存的程序代碼中抽取有關數據、體系結構和處理過程的設計信息。

4，代碼重構

代碼重構是最常見的再工程活動。某些老程序具有比較完整、合理的體系結構，但是，個體模塊的編碼方式卻是難于理解、測試和維護的。在這種情況下，可以重構可疑模塊的代碼。

? ? ? ? 首先，用重構工具分析源代碼，標注出和結構化程序設計概念相違背的部分

? ? ? ? 然后，重構有問題的代碼（此項工作可自動進行）

? ? ? ? 最后，復審和測試生成的重構代碼（以保證沒有引入異常）并更新代碼文檔。

5，數據重構

?????? 與代碼重構不同，數據重構發生在相當低的抽象層次上，它是一種全范圍的再工程活動——對數據的修改必然會導致體系結構或代碼層的改變。在大多數情況下，數據重構始于逆向工程活動，分解當前使用的數據體系結構，必要時定義數據模型，標識數據對象和屬性，并從軟件質量的角度復審現存的數據結構。

?????? 當數據結構較差時（例如在關系型方法可大大簡化處理的情況下卻使用平坦文件實現），應該對數據進行再工程。

6，正向工程

?????? 正向工程也稱為革新或改造，這項活動不僅從現有程序中恢復設計信息，而且使用該信息去改變或重構現有系統，以提高其整體質量。

總結

以上是生活随笔為你收集整理的软件工程：维护的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。