199.維護

第8章  維護

基本任務：

    是保證軟件在一個至關長的時期可以正常運行。

 

    軟件維護須要的工做量很大，60%以上的人力用於維護已有的軟件，隨着投入使用的軟件數量增多和使用壽命延長，這個百分比還在持續上升。最終致使軟件開發組織沒有餘力開發新的軟件。

 

軟件工程的目的：

    要提升軟件的可維護性，減小軟件維護所須要的工做量，下降軟件系統的總成本。

 

8.1  軟件維護的定義

軟件維護：

    在軟件已經交付使用以後，爲了改正錯誤或知足新的須要而修改軟件的過程。

    能夠經過如下4項活動，具體地定義軟件維護。

 

•四種維護類型：

 改正性維護

 適應性維護

 完善性維護

  預防性維護

 

1.改正性維護

    在軟件交付使用後，因開發時測試的不完全、不徹底，必然會有部分隱藏的錯誤遺留到運行階段。

    這些隱藏下來的錯誤在某些特定的使用環境下就會暴露出來。

    爲了識別和糾正軟件錯誤、改正軟件性能上的缺陷、排除實施中的誤使用，應當進行的診斷和改正錯誤的過程。

 

2.適應性維護

  在使用過程當中，外部環境、數據環境可能發生變化。

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

 數據環境（數據庫、數據格式、數據輸入/輸出方式、數據存儲介質）

適應性維護：爲使軟件適應這種變化，而去修改軟件的過程。

 

3.完善性維護

•在軟件的使用過程當中，用戶每每會對軟件提出新的功能與性能要求。

•完善性維護：

    爲了知足上述要求，須要修改或再開發軟件而進行的完善性的維護活動。以擴充軟件功能、加強軟件性能、改進加工效率、提升軟件的可維護性。

•完善性維護不必定是救火式的緊急維修，能夠是有計劃、有預謀的一種再開發活動。

 

4.預防性維護

•預防性維護：

   爲了提升軟件的可維護性、可靠性等，爲之後進一步改進軟件打下良好基礎而修改軟件的維護活動。

•預防性維護的定義：

   採用先進的軟件工程方法對須要維護的軟件或軟件中的某一部分（從新）進行設計、編制和測試的過程。

 

國外的統計數字代表：

完善性維護佔所有維護活動的50%～66%，

改正性維護佔17%～21%，

適應性維護佔18%～25%，

其餘維護活動只佔4%左右。

 

完善性維護佔了幾乎一半的工做量。

可見：

大部分維護工做是改變和增強軟件，不是糾錯。

 

8.2  軟件維護的特色 

 8.2.1  結構化維護與非結構化維護差異巨大

1. 非結構化維護

    若是軟件配置的唯一成分是程序代碼，

•那麼維護活動從艱苦地評價程序代碼開始。

•沒有設計文檔及測試文檔。

    非結構化維護須要付出很大代價，這種維護方式是沒有使用良好的方法學開發出來的軟件的必然結果。

 

2. 結構化維護

    若是有一個完整的軟件配置存在，

•那麼維護工做從評價設計文檔開始；

•估量要求的改動將帶來的影響，而且計劃實施途徑。

•而後修改設計而且對所作的修改進行仔細複查。

•編寫相應的源程序代碼；

•使用在測試說明書中包含的信息進行迴歸測試；

•把修改後的軟件再次交付使用。

 

8.2.2  維護的代價高昂

•軟件維護活動所花費的工做佔整個生存期工做量的70%以上。

  在漫長的軟件運行過程當中須要不斷對軟件進行修改，以改正新發現的錯誤、適應新的環境和用戶新的要求，這些修改須要花費不少精力和時間，並且有時會引入新的錯誤。

•維護費用是軟件維護的最明顯的代價，還有一些無形的代價。

無形的代價還有：

•可用的資源必須供維護任務使用，以至耽誤甚至喪失了開發的良機。

•改錯或修改的不及時，引發的用戶不滿；

•因爲維護時的改動，在軟件中引入了潛伏的錯誤，從而下降了軟件的質量；

•把軟件工程師調去從事維護工做，在開發過程當中形成的混亂。

•生產率的大幅度降低，尤爲在維護舊程序時經常遇到。

 

維護工做量的一個模型：M = P + K × exp(c-d)

其中：

• M是維護用的總工做量，

• P是生產性工做量（分析等必要的過程） ，

• K是經驗常數，

• c是複雜程度(非結構化設計和缺乏文檔都會增長軟件的複雜程度)，

• d是維護人員對軟件的熟悉程度。

模型代表：

    若是軟件的開發途徑很差(沒有使用軟件工程方法學)，並且原來的開發人員不能參加維護工做，那麼維護工做量和費用將指數地增長。

 

8.2.3  維護的問題不少

    存在於沒采用軟件工程思想開發出來的軟件中：

（1） 僅有程序代碼沒有說明文檔；。

（2） 缺乏容易理解的而且和程序代碼徹底一致的文檔；

（3） 不能期望由開發人員給咱們仔細說明軟件。因爲維護階段持續的時間很長，寫程序的人已經不在了。

（4） 絕大多數軟件在設計時沒有考慮未來的修改。沒有使用模塊獨立的原理去的設計，使修改軟件既困難又容易發生差錯。

   因此，應採用軟件工程思想來開發軟件

 

8.3  軟件維護過程

• 先創建一個維護組織；

• 肯定報告和評價的過程；

• 爲每一個維護要求規定一個標準化的事件序列；

• 創建一個適用於維護活動的記錄保管過程；

• 規定複審標準。

 

1. 維護組織

對於每一個維護要求：

•經過維護管理員轉交給相應的系統管理員去評價。

    系統管理員對維護任務作出評價以後，

•由變化受權人決定應該進行的活動。

 

圖8.1描繪了上述組織方式。

目的：在維護活動開始以前就明確維護責任。

 

圖8.1 維護組織

 

2. 維護報告

• 應該用標準化的格式表達全部軟件維護要求。

• 軟件維護人員一般給用戶提供空白的維護要求表——有時稱爲軟件問題報告表。

    這個表格由要求維護活動的用戶填寫。

    由維護管理員和系統管理員評價用戶提交的維護要求表。

 

3. 維護的事件流

圖8.2描繪了由一項維護要求而引出的一串事件。

•首先應該肯定要求進行的維護的類型。

•改正性維護要求：

    估量錯誤的嚴重程度；

    是一個嚴重的錯誤，在系統管理員的指導下分派人員，當即開始問題分析過程；

    錯誤並不嚴重，與其餘的軟件開發任務一塊兒統籌安排。

•適應性維護和完善性維護要求：

    應該肯定每一個維護要求的優先次序；

    安排要求的工做時間；

    若是優先次序很是高，可能當即開始維護工做。

 

軟件維護工做流程

 

4. 保存維護記錄

①程序標識；②源語句數； ③機器指令條數；

④使用的程序設計語言；⑤程序安裝的日期；

⑥自從安裝以來程序運行的次數；

⑦自從安裝以來程序失效的次數；

⑧程序變更的層次和標識；

⑨因程序變更而增長的源語句數；

    因程序變更而刪除的源語句數； 每一個改動耗費的人時數； 程序改動的日期； 軟件工程師的名字； 維護要求表的標識； 維護類型； 維護開始和完成的日期； 累計用於維護的人時數； 與完成的維護相聯繫的純效益。

 

5. 評價維護活動

從下述7個方面度量維護工做：

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

(2) 用於每一類維護活動的總人時數；

(3) 平均每一個程序、每種語言、每種維護類型所作的程序變更數；

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

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

(6) 一張維護要求表的平均週轉時間；

(7) 不一樣維護類型所佔的百分比。

    由此作出關於開發技術、語言選擇、維護工做量規劃、資源分配等方面的決定。

 

8.4  軟件的可維護性

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

    提升可維護性是軟件開發階段各個時期的關鍵目標。

8.4.1  決定軟件可維護性的因素

維護：就是在軟件交付使用後進行的修改。

•修改以前必須理解待修改的對象，

•修改以後應該進行必要的測試，以保證所作的修改是正確的。

•若是是改正性維護，還必須預先進行調試以肯定錯誤的具體位置。

 

所以，決定軟件可維護性的因素主要有下述5個：

   可理解性，可測試性，可修改性，可移植性，

   可重用性

 

1. 可理解性

•可理解性：外來讀者理解軟件的結構、功能、接口和內部處理過程的難易程度。

•影響因素：

    模塊化（模塊結構良好，高內聚，鬆耦合）、詳細的設計文檔、結構化設計、程序內部的文檔和良好的高級程序設計語言等等。

 

2. 可測試性

•可測試性：論證程序正確性的容易程度。

•模塊的環形複雜度可度量它的可測試性。

    模塊的環形複雜度越大，可執行的路徑就越多，全面測試它的難度就越高。

•影響因素：

良好的文檔，軟件結構、測試工具和調試工具，之前測試時設計的測試過程。

 

3. 可修改性

可修改性：軟件容易修改的程度。

影響因素：耦合、內聚、信息隱藏、局部化、控制域與做用域的關係等等。

 

4. 可移植性

可移植性：把程序從一種計算環境（硬件配置和操做系統）轉移到另外一種計算環境的難易程度。

對策：

    把與硬件、操做系統及其餘外部設備有關的程序代碼集中放到特定的程序模塊中，受環境變化影響的僅有少數程序模塊，從而下降修改的難度。

 

5. 可重用性

重用（reuse）：同一事物不作修改或稍加改動就在不一樣環境中屢次重複使用。

使用可重用的構件來開發軟件，能夠提升軟件的可維護性：

• 軟件中使用的可重用構件越多，軟件的可靠性越高，改正性維護需求越少。

• 很容易修改可重用的軟件構件使之再次應用在新環境中，所以，軟件中使用的可重用構件越多，適應性和完善性維護也就越容易。

 

8.4.2  文檔

文檔：是影響軟件可維護性的決定因素。

    大型軟件系統在長期的使用過程當中必然會經受屢次修改，因此文檔比程序代碼更重要。

文檔分類：

•系統文檔：描述系統設計、實現和測試等一系列和系統實現有關的文檔。

•用戶文檔：描述系統功能和使用方法，並不關心這些功能怎樣實現。包括：

功能描述；安裝文檔；使用手冊；參考手冊；操做員指南。

 

用戶文檔應包括的5方面內容：

(1) 功能描述，說明系統能作什麼；

(2) 安裝文檔，說明怎樣安裝這個系統以及怎樣使系統適應特定的硬件配置；

(3) 使用手冊，經過豐富例子說明怎樣使用經常使用的系統功能，及用戶操做錯誤時怎樣恢復和從新啓動；

(4) 參考手冊，詳盡描述用戶可使用的全部系統設施及使用方法，解釋系統可能產生的各類出錯信息的含義；

(5) 操做員指南(若是須要的話)，說明操做員應該如何處理使用中出現的各類狀況。

 

8.4.3  可維護性複審

•在軟件工程過程的每個階段都應該努力提升軟件的可維護性，在每一個階段結束前的技術審查和管理複審中，應該着重對可維護性進行復審。

    從需求分析到設計與編碼等各階段。

•在完成了每項維護工做以後，都應該對軟件維護自己進行仔細認真的複審。

•維護應該針對整個軟件配置，不該該只修改源程序代碼。

 

8.5  預防性維護

產生背景:

存在這樣一些程序：

•體系結構和數據結構都不好，

•文檔不全甚至徹底沒有文檔，

•對曾經作過的修改也沒有完整的記錄。

•但仍然在爲用戶服務。

怎樣知足用戶對這類程序的維護要求呢？

 

有如下幾種作法可供選擇：

（1） 反覆屢次地作修改程序的嘗試，與不可見的設計及源代碼「頑強戰鬥」，以實現所要求的修改；

    該作法很盲目，一般人們採用後3種作法。

（2） 經過仔細分析程序儘量多地掌握程序的內部工做細節，以便更有效地修改它；

（3） 在深刻理解原有設計的基礎上，用軟件工程方法從新設計、從新編碼和測試那些須要變動的軟件部分；

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

 

 

•由Miller提出的。

•定義：「把今天的方法學應用到昨天的系統上，以支持明天的需求。」

依據：

（1） 維護一行源代碼的代價多是最初開發該行源代碼代價的14~40倍；

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

 

依據：

（3） 因爲現有的程序版本可做爲軟件原型使用，開發生產率可大大高於平均水平；

（4） 用戶具備較多使用該軟件的經驗，所以，可以很容易地搞清新的變動需求和變動的範圍；

（5） 利用逆向工程和再工程的工具，可使一部分工做自動化；

（6） 在完成預防性維護的過程當中能夠創建起完整的軟件配置。

 

8.6  軟件再工程過程

過程模型如圖8.3所示，定義了6類活動。

    再工程範型是一個循環模型。每一個活動均可能被重複，過程能夠在完成任意一個活動以後終止。

 

圖8.3 軟件再工程過程模型

 

下面簡要地介紹該模型所定義的6類活動。

1. 庫存目錄分析

•每一個軟件組織都應該保存其擁有的全部應用系統的庫存目錄。

•該目錄包含關於每一個應用系統的基本信息（例如，應用系統的名字，最初構建它的日期，已作過的實質性修改次數，過去18個月報告的錯誤，用戶數量，安裝它的機器數量，它的複雜程度，文檔質量，總體可維護性等級，預期壽命，在將來36個月內的預期修改次數，業務重要程度等）。

•庫存目錄分析：分析哪些須要進行再工程過程。

有3類程序：

（1） 預約將使用多年的程序；

（2） 當前正在成功地使用着的程序；

（3） 在最近的未來可能要作重大修改或加強的程序。

 

2. 文檔重構

老程序固有的特色是缺少文檔。處理方法：

（1） 若是一個程序是相對穩定的，正在走向終點，保持現狀，不建文檔。

（2） 只針對系統中當前正在修改的那些部分創建完整文檔。隨着時間流逝，將獲得一組有用的和相關的文檔。

（3） 若是某應用系統是完成業務工做的關鍵，並且必須重構所有文檔，也設法把文檔工做減小到必需的最小量。

 

3. 逆向工程

•軟件的逆向工程：是分析程序以便在比源代碼更高的抽象層次上建立出程序的某種表示的過程；

•逆向工程是一個恢復設計結果的過程；

•逆向工程工具從現存的程序代碼中抽取有關數據、體系結構和處理過程的設計信息。

 

4. 代碼重構

•代碼重構是最多見的再工程活動。

•某些老程序具備比較完整、合理的體系結構，可是，個體模塊的編碼方式倒是難於理解、測試和維護的，可進行代碼重構。

•重構過程：分析源代碼→標註需重構部分→重構→複審、測試→更新文檔。

•重構並不修改總體的程序體系結構，它僅關注個體模塊的設計細節以及在模塊中定義的局部數據結構。

•若是重構擴展到模塊邊界以外，並涉及軟件體系結構，則重構變成了正向工程。

 

5. 數據重構

•對數據體系結構差的程序很難進行適應性修改和加強；

•數據體系結構比源代碼自己對程序的長期生存力有更大影響；

•因爲數據體系結構對程序體系結構及算法有很大影響，對數據的修改必然會致使體系結構或代碼層的改變。

•當數據結構較差時，應該對數據進行再工程。

 

6. 正向工程

•正向工程也稱爲革新或改造；

•不只從現有程序中恢復設計信息，並且使用該信息去改變或重構現有系統，以提升其總體質量。

•被再工程的軟件不只從新實現現有系統的功能，並且加入了新功能和提升了總體性能。

 

8.7  小結

維護是軟件生命週期的最後一個階段，也是持續時間最長代價最大的一個階段。

軟件維護一般包括4類活動：

爲了糾正在使用過程當中暴露出來的錯誤而進行的改正性維護；

爲了適應外部環境的變化而進行的適應性維護；

爲了改進原有的軟件而進行的完善性維護；

以及爲了改進未來的可維護性和可靠性而進行的預防性維護。

 

軟件的可理解性、可測試性、可修改性、可移植性和可重用性，是決定軟件可維護性的基本因素。

軟件重用技術能從根本上提升軟件可維護性。

軟件生命週期每一個階段的工做都和軟件可維護性有密切關係。所以，在軟件生命週期的每一個階段都必須充分考慮維護問題，而且爲軟件維護預作準備。

文檔是影響軟件可維護性的決定因素，甚至比程序代碼更重要。文檔必須和程序代碼同時維護。

雖然因爲維護資源有限，目前預防性維護在所有維護活動中僅佔很小比例，但在條件具有時應該主動地進行預防性維護。

預防性維護實質上是軟件再工程。