《軟件工程》課件第13章

第13章軟件維護了解維護的概念，掌握四類維護了解維護過程、軟件的可維護性ZLL第13章 軟件維護軟件維護是軟件生命周期的最后一個階段，軟件從部署完畢到退役的整個時間內對軟件的改動所做的工作都是維護的內容。在項目的各個階段對項目的可維護性進行充分考慮、對可維護性的嚴格評審以及在維護階段有效地組織和管理維護活動，則是保證軟件可維護性和降低維護費用的關鍵。本章重點內容：維護的主要內容、維護的流程、如何在軟件的生產過程各個階段保證軟件的可維護性目標。ZLL13.1軟件維護概述軟件維護的主要目標是使已部署的軟件按照需求規(guī)格說明書的要求（或用戶的新需求）運行，這要求軟件不僅要滿足用戶所需要的各項功能需求，同時還要滿足用戶對軟件的非功能需求。軟件維護的基本內容則包含了實現(xiàn)這些目標所做的全部工作。ZLL13.1.1軟件維護的定義按照維護的起因分類：糾錯性維護適應性維護改善性維護預防性維護四類。1.糾錯性維護——為改正軟件系統(tǒng)中潛藏的錯誤而進行的活動。用戶在使用軟件過程中發(fā)現(xiàn)軟件的錯誤是激發(fā)該種維護的起因。四類ZLL2.適應性維護——為適應軟件運行環(huán)境的變化而修改軟件的活動。軟件的運行環(huán)境包括兩個方面，硬件和軟件，軟件則大體上包括操作系統(tǒng)、中間件、虛擬機等等。13.1.1軟件維護的定義ZLL3.改善性維護——根據(jù)用戶在軟件使用過程中提出的建設性意見而進行的維護活動。主要是針對用戶提出的新的軟件需求或修改原有的軟件需求而進行的維護，該種維護通常占所有維護工作量的一半以上。軟件在部署之后一段時間內，用戶的改善性維護應該是遞減的。13.1.1軟件維護的定義ZLL4.預防性維護——為了進一步改善軟件系統(tǒng)的可維護性和可靠性，并為以后的改進奠定基礎。預防性維護可以采取逆向工程（reverseengineering）和重構工程（re-engineering）方式。13.1.1軟件維護的定義ZLL嚴格按照軟件工程標準生產的軟件產品在維護過程中糾錯性維護的工作量很低，不到總維護工作量的1／5。由于改善性維護和適應性維護需要修改需求規(guī)格說明書，應按照需求變更來進行管理，相當于螺旋模型中的又一次迭代過程，因此工作量很大。13.1.1軟件維護的定義ZLL13.1.2影響維護工作的因素1．系統(tǒng)大小系統(tǒng)越大，越復雜，維護人員理解起來就越困難。因而需要更多的維護工作量?？捎迷闯绦蛘Z句數(shù)，輸入輸出文件數(shù)，實現(xiàn)的功能模塊數(shù)量來衡量系統(tǒng)的大小。2．系統(tǒng)的開發(fā)文檔系統(tǒng)的開發(fā)文檔完善，維護工作就好做很多。開發(fā)文檔不完善，則維護的工作量將會很大，因為要通過源程序去閱讀，理解一個程序的功能和設計思想將是非常困難的。3．其他因素在程序中使用的數(shù)學模型、任務的難度、IF嵌套深度、索引或下標數(shù)等，對維護工作量都有影響。ZLL13.1.3維護成本軟件的維護成本體現(xiàn)為有形和無形兩類。有形的軟件維護成本是花費了多少錢，無形的成本是對其他方面的影響，可以是以下幾種：（1）維護不及時和不能滿足用戶新的功能需求，使得用戶不滿意。（2）在維護時因引入了新的錯誤，使軟件整體質量下降，從而造成更大的維護活動。（3）當必須把軟件人員抽調到維護工作中去時，影響正在進行的軟件開發(fā)工作。軟件維護的代價是在生產率（用LOC/PM或功能點/PM度量）方面驚人的下降。有報告說，生產率將降到原來的1/40。維護工作量可以分成生產性活動（如分析和評價，設計修改和實現(xiàn)）和“輪轉”活動（如力圖理解代碼在做什么、試圖判明結構、接口特性、性能界限等）。ZLL13.2軟件可維護性對于一個復雜的軟件系統(tǒng)，造成維護工作十分困難的一個直接原因是缺乏軟件開發(fā)文檔。因為沒有足夠的、規(guī)范的文檔，很難理解以前的軟件的功能、算法，很難閱讀和理解源程序。但實際上，最根本的原因是沒有嚴格按照軟件工程的規(guī)范和標準來開發(fā)軟件，在維護時也沒有按照規(guī)范來做，為以后的維護帶來了更多的問題。所以，為了使得軟件能夠易于維護，首先必須考慮使軟件具有可維護性。ZLL13.2.1軟件可維護性的定義

可維護性、可使用性、可靠性是衡量軟件質量的幾個主要質量特性，也是用戶十分關心的幾個方面。軟件的可維護性是軟件開發(fā)階段各個時期的關鍵目標。目前廣泛使用的是如下的七個特性來衡量軟件的可維護性。而且對于不同類型的維護，這七種特性的側重點也不相同。表13-1顯示了在各類維護中應側重哪些特性。表中的“√”表示特別需要的特性。軟件可維護性就是指進行維護活動時的容易程度。類別改正性維護適應性維護完善性維護可理解性√可測試性√可修改性√√可靠性√可移植性√可使用性√√效率√ZLL13.2.2可維護性的度量在對軟件質量的量化追求中，形成了一個新的學科——軟件度量學。下面介紹度量一個可維護的程序的七種特性時常用的方法。這就是質量檢查表、質量測試、質量標準。質量檢查表是一個問題清單，評價者針對檢查表上的每一個問題，依據(jù)自己的定性判斷，回答“Yes”或“No”。用這個清單對質量進行分析。質量測試與質量標準則用于定量分析和評價程序的質量。下面是對這七種特性的描述。1．可理解性2．可靠性3．可測試性4．可修改性5．可移植性6．效率7．可使用性8．其他間接定量度量可維護性的方法Gilb提出了與軟件維護期間工作量有關的一些數(shù)據(jù)，可以使用它們間接地對軟件的可維護性做出估計。ZLL13.2.3可維護性復審可維護性是軟件工程所追求的一個目標。在軟件工程每一階段的復審中，可維護性都是一個重要的指標。在需求分析階段的復審中，應在規(guī)格說明書中對將來可能修改和可以改進的部分加以注明；在設計階段的復審中，應該從易于維護和提高設計總體質量的角度對設計進行全面評審；代碼復審主要審查代碼風格和內部文檔（程序注釋等）這兩個直接影響可維護性的因素。最后，每一階段性測試（直到軟件正式交付之前）都應該進行預防性的維護。正式的可維護性復審放在測試完成之后，稱為配置復審。目的是保證配置中所有成分的完整、一致、易于理解且便于修改控制。ZLL13.3軟件維護的特點1．非結構化維護因為只有源程序，而文檔很少或沒有文檔，維護活動只能從閱讀、理解和分析源程序開始。也只有通過閱讀源程序來了解系統(tǒng)功能、軟件結構、數(shù)據(jù)結構、系統(tǒng)接口和設計約束等。要完成這些工作是非常困難的。要想搞清楚，要花費大量的人力、物力，最終對源程序修改的后果還是難以估量的，難以估計軟件的質量。因為沒有測試文檔，不可能進行回歸測試，很難保證程序的正確性。2．結構化維護用軟件工程思想開發(fā)的軟件具有各個階段的文檔，這對于理解、掌握軟件功能、性能、軟件結構、數(shù)據(jù)結構、系統(tǒng)接口和設計約束有很大作用。進行維護活動時，需從評價需求說明開始，搞清楚軟件功能、性能上的改變；對設計說明文檔進行評價，對設計說明文檔進行修改和復查；根據(jù)設計的修改，進行程序的變動；根據(jù)測試文檔中的測試用例進行回歸測試。ZLL是否維護要求評價設計閱讀源代碼計劃途徑定位錯誤修改設計重編程序重編程序交付使用回歸測試是否結構化回歸測試圖13-1結構化維護和非結構化維護13.3軟件維護的特點ZLL13.3.2維護的困難性（1）讀懂別人的源程序是困難的。（2）文檔的不一致性（3）軟件開發(fā)和軟件維護在人員和時間上的差異（4）軟件維護不是一項具有吸引力的工作ZLL13.3軟件維護的費用1990年1980年1970年占總費用的35%—40%占總費用的35%—40%占總費用的35%—40%

維護活動的總工作量由下式表示：M=P+K·exp(C–D)其中：M表示維護工作的總工作量（人年/人月）；P表示生產性活動工作量；K表示經驗常數(shù)；C表示復雜性程度；D表示維護人員對軟件的熟悉程度。上式表明，若C越大，D越小，那么維護工作量將成指數(shù)增加；C增加表示軟件因未用軟件工程方法開發(fā)，文檔缺少，程序復雜性高；D表示對軟件熟悉程度，如果維護人員不是開發(fā)人員，則重新理解軟件會花費很多時間，造成總的維護費用上升。ZLL13.4軟件維護的實施——13.4.1維護的組織

為軟件維護活動建立維護機構，通常以維護小組形式出現(xiàn)，分為臨時和長期兩種類型。1．臨時維護小組執(zhí)行一些特殊的或臨時的維護任務。例如，對程序排錯的檢查，檢查完善性維護的設計和進行質量控制的復審等。無論臨時維護小組的任務如何簡單，給小組的成員清晰的責任應是很重要的，以免因為維護過程中的責任不清而造成混亂。2．長期維護小組對長期運行的復雜系統(tǒng)進行維護必須有一個穩(wěn)定的維護小組才可以完成任務。維護小組在系統(tǒng)開發(fā)完成之前就應該成立，小組必須有嚴格的組織。一般有如下的組成成員：（1）組長組長應對維護小組的一切活動負責。負責向上級主管部門報告維護工作，并負責小組的維護工作管理。組長是該小組的技術負責人，有較高的技術水平，并具有一定的管理經驗，熟悉系統(tǒng)的應用領域。（2）副組長副組長是組長的助手，具體負責同開發(fā)部門或其他維護小組聯(lián)系。在系統(tǒng)開發(fā)階段，收集與維護有關的信息；在維護階段，他同開發(fā)者繼續(xù)保持聯(lián)系，向他們傳送程序運行的反饋信息。因為在維護活動中的改正性維護大多是由用戶提出的，所以副組長應該同用戶保持密切聯(lián)系。（3）維護程序員維護程序員負責分析程序的錯誤，并執(zhí)行修改工作。要求維護程序員不僅熟悉編程，還應該具有軟件開發(fā)和維護方面的知識和經驗，還應熟悉程序應用領域的知識。ZLL13.4.2維護的流程軟件維護活動和軟件開發(fā)一樣，要有嚴格的規(guī)范，才能保證軟件的質量。一般執(zhí)行維護活動的流程如下：（1）制定維護申請報告。（2）審查申請報告并批準。（3）進行維護并做詳細記錄。（4）復審。1．制定維護申請報告應該以文檔的形式提出所有軟件維護申請。由申請維護的人員填寫。對于改正性的維護申請報告必須盡量完整地說明錯誤產生的場景，包括運行時的環(huán)境、輸入數(shù)據(jù)、錯誤提示以及其他有關材料。但是要注意，由于設計的問題，對運行時出現(xiàn)的錯誤不一定再現(xiàn)。對于適應性或完善性的維護要求，則要提交一份簡要的維護要求說明。一切維護活動都應該是從維護申請報告開始。對維護申請報告分析、評價后，在軟件維護組織內部還要制定一份軟件修改報告，該報告是維護階段的另一種文檔，用來指出：（1）為滿足軟件問題報告實際要求的工作量。（2）要求修改的類型。（3）請求修改的優(yōu)先權。（4）關于修改的事后數(shù)據(jù)。提出維護申請報告之后，由維護機構來評審維護請求。將評價維護的類型，是改正性的還是改進性的，然后根據(jù)問題的嚴重性安排維護工作，適時開始具體的維護活動。ZLL13.4.2維護的流程2．維護過程一個維護申請?zhí)岢鲋?，經評審需要維護，則按下列過程實施維護：（1）首先確定要進行維護的類型。要確定維護的類型是改正性的還是改進性的，從用戶的觀點和維護小組的觀點出發(fā)得到的結果不一定是相同的。要與用戶協(xié)商解決這個問題。（2）對改正性維護從評價錯誤的嚴重性開始。如果存在一個嚴重的錯誤（如一個系統(tǒng)的重要功能不能執(zhí)行），則由管理人員立即組織有關人員開始分析問題。如果錯誤不嚴重，則將改正性維護與軟件其他維護任務一起進行，統(tǒng)一安排維護工作。甚至經過評審后發(fā)現(xiàn)申請是錯誤的，并不需要進行維護活動。（3）對適應性和完善性維護。對問題進行評審，確定問題的優(yōu)先級。如果優(yōu)先級低，則看成是另一個開發(fā)工作，安排所要求的工作，如果優(yōu)先級高，需要立即開始分析問題，進入此項維護工作。（4）實施維護任務。不管維護類型如何，大體上要開展相同的技術工作。這些工作包括分析軟件的需求、修改軟件設計、修改源程序、單元測試、集成測試、確認測試以及復審，在每個階段都要有詳細的文檔。但是，對不同的維護類型，工作的側重點不一樣。（5）“救火”維護。對于有的維護申請，需要立即進行修改維護，這時申請的維護稱為“救火”維護。顯然，如果一個軟件開發(fā)機構經?！熬然稹保捅仨氁J真檢查一下，該機構的管理和技術存在什么重大問題。3．維護的復審在維護任務完成后，要對維護任務進行復審。進行復審時要回答下列問題：（1）評價維護的情況，即設計、編碼和測試的哪些方面已經完成？（2）對軟件開發(fā)工作有哪些改進要求？（3）對于維護工作，主要的、次要的障礙是什么？復審對將來的維護工作能否順利進行有重大影響，對一個軟件機構來說也是正規(guī)、有效的管理工作的一部分。ZLL13.4.3維護技術1．面向維護的技術——面向維護的技術涉及軟件開發(fā)的所有階段。在需求分析階段，保證對用戶的需求沒有矛盾和易于理解，可以減少軟件中的錯誤在設計階段，考慮計算機的發(fā)展趨勢，充分考慮將來改動或擴充的可能性。使用先進的設計思想和工具。在測試階段，設計完善的測試方法，盡量發(fā)現(xiàn)存在的錯誤，保存測試用例和測試結果等。在每個階段都要有詳細、規(guī)范的文檔，這些技術方法都能減少軟件錯誤，提高軟件的可維護性。2．維護支援技術維護支