[軟工導論]第8章 軟件維護

1、1,第八章 軟 件 維 護普通人輕視軟件維護工作， 會失掉極其寶貴的機會； 維護人員輕視軟件維護工作， 會失掉本應(yīng)精彩的人生； 老板輕視軟件維護工作， 會丟掉大片本來屬于自己的市場,2,第八章 軟件維護,8.1 軟件維護的定義 軟件維護 - 就是在軟件已經(jīng)交付使用之后，為保證軟件在相當長的時期能夠正常運作所進行的軟件活動。 維護的類型有四種： 改正性維護 適應(yīng)性維護 擴充與完善性維護 預(yù)防性維護,3,改正性維護 - Corrective Maintenance 在軟件交付使用后，因開發(fā)時測試的不徹底、不完全，必然會有部分隱藏的錯誤遺留到運行階段。 這些隱藏下來的錯誤在某些特定的使用環(huán)境下就會暴

2、露出來。 為了識別和糾正軟件錯誤、改正軟件性能上的缺陷、排除實施中的誤使用，所進行的診斷和改正錯誤的過程就叫做改正性維護。,4,適應(yīng)性維護 - Adaptive Maintenance,在使用過程中， 外部環(huán)境（新的硬、軟件配置） 數(shù)據(jù)環(huán)境（數(shù)據(jù)庫、數(shù)據(jù)格式、數(shù)據(jù)輸入/輸出方式、數(shù)據(jù)存儲介質(zhì)） 可能發(fā)生變化。 為使軟件適應(yīng)這種變化，而去修改軟件的過程就叫做適應(yīng)性維護。,5,擴充與完善性維護 - Perfective Maintenance,在軟件的使用過程中，用戶往往會對軟件提出新的功能與性能要求。 為了滿足這些要求，需要修改或再開發(fā)軟件，以擴充軟件功能、增強軟件性能、改進加工效率、提高軟件的

3、可維護性。 這種情況下進行的維護活動叫做擴充與完善性維護。,6,預(yù)防性維護 - Preventive Maintenance,預(yù)防性維護是為了提高軟件的可維護性、可靠性等，為以后進一步改進軟件打下良好基礎(chǔ)。 預(yù)防性維護定義為：采用先進的軟件工程方法對需要維護的軟件或軟件中的某一部分（重新）進行設(shè)計、編制和測試。,7,各種維護所占比例:,其它維護 4 %,適應(yīng)性維護 18% 25%,改正性維護 17% 21%,擴充與完善性維護 50% 66%,8,8.2 軟件維護的特點 - 影響維護工作量的因素,系統(tǒng)大小：系統(tǒng)越大，理解掌握起來越困難。系統(tǒng)越大，所執(zhí)行功能越復雜。因而需要更多的維護工作量。 程序

4、設(shè)計語言：使用強功能的程序設(shè)計語言可以控制程序的規(guī)模。語言的功能越強，生成程序的模塊化和結(jié)構(gòu)化程度越高，所需的指令數(shù)就越少，程序的可讀性越好。,9,系統(tǒng)年齡： 老系統(tǒng)隨著不斷的修改，結(jié)構(gòu)越來越亂； 維護人員經(jīng)常更換，程序又變得越來越難于理解 許多老系統(tǒng)在當初并未按照軟件工程的要求進行開發(fā)，因而沒有文檔，或文檔太少。 在長期的維護過程中文檔在許多地方與程序?qū)崿F(xiàn)變得不一致，在維護時就會遇到很大困難。 數(shù)據(jù)庫技術(shù)的應(yīng)用：使用數(shù)據(jù)庫，可以簡單而有效地管理和存儲用戶程序中的數(shù)據(jù)，還可以減少生成用戶報表應(yīng)用軟件的維護工作量。,10,先進的軟件開發(fā)技術(shù)：在軟件開發(fā)時，若使用能使軟件結(jié)構(gòu)比較穩(wěn)定的分析與設(shè)計技

5、術(shù)，及程序設(shè)計技術(shù)，如面向?qū)ο蠹夹g(shù)、復用技術(shù)等，可減少大量的工作量。 其它： 應(yīng)用的類型 數(shù)學模型 任務(wù)的難度 開關(guān)與標記、IF嵌套深度、索引或下標數(shù)等 對維護工作量都有影響。 許多軟件在開發(fā)時并未考慮將來的修改，為軟件的維護帶來許多問題。,11,維護成本,有形的軟件維護成本是花費了多少錢，無形的維護成本有更大的影響。 可用的資源必須供維護任務(wù)使用,以致耽誤甚至喪失開發(fā)的良機; 一些合理的修復或修改請求不能及時安排，使得客戶不滿意； 變更的結(jié)果引入新的故障，使得軟件整體質(zhì)量下降； 把軟件人員抽調(diào)到維護工作中，干擾了軟件開發(fā)工作。,12,維護工作量的模型,M 是維護中消耗的總工作量 P 是生產(chǎn)性

6、工作量 K 是一個經(jīng)驗常數(shù) c 是因缺乏好的設(shè)計和文檔而導致復雜性的度量 d 是維護人員對軟件熟悉程度的度量 模型指明，如果使用了不好的軟件開發(fā)方法（未按軟件工程要求做），原來參加開發(fā)的人員或小組不能參加維護，則工作量（及成本）將按指數(shù)級增加。,13,8.2.3 維護中的典型問題,(1) 難以跟蹤軟件版本的進化過程,軟件的變化未在文檔中反映出來. (2) 難以跟蹤軟件的創(chuàng)建過程. (3) 難以讀懂他人程序. (4) 無文檔或不全. (5) 軟件人員流動性大. (6) 設(shè)計時未考慮修改需要,修改困難. 維護工作無吸引力,缺乏成就感. 采用軟件工程方法至少可部分地解決與維護有關(guān)的每一個問題。,14

7、,8.3 軟件維護過程,維護過程本質(zhì)上是修改和壓縮了的軟件定義和開發(fā)過程，而且事實上遠在提出一項維護要求之前，與軟件維護有關(guān)的工作已經(jīng)開始了。 為了有效地進行軟件維護，應(yīng)事先就開始做組織工作。 首先建立維護的機構(gòu) 申明提出維護申請報告的過程及評價的過程 為每一個維護申請規(guī)定標準的處理步驟 建立維護活動的記錄保管，并規(guī)定復審的標準,15,1、維護機構(gòu),除了較大的軟件開發(fā)公司外，通常在軟件維護工作方面，并不保持一個正式的組織機構(gòu)。 雖然不要求建立一個正式的維護機構(gòu)，但是在開發(fā)部門確立一個非正式的維護機構(gòu)則是非常必要的。,16,每個維護要求都通過維護管理員轉(zhuǎn)交給相應(yīng)的系統(tǒng)管理員去評價（系統(tǒng)管理員是被

8、指定去熟悉一小部分產(chǎn)品程序的技術(shù)人員）。 系統(tǒng)管理員對維護任務(wù)做出評價之后，由變化授權(quán)人決定應(yīng)該進行的活動。,17,2. 維護報告 應(yīng)該用標準化的格式表達所有軟件維護申請（要求）。 維護申請報告或稱軟件問題報告，由申請維護的用戶填寫。 用戶必須完整地說明產(chǎn)生錯誤的情況，包括輸入數(shù)據(jù)、錯誤清單以及其它有關(guān)材料。 如果申請的是適應(yīng)性維護或完善性維護，用戶必須提出一份修改說明書，列出所有希望的修改。,18,維護申請報告將由維護管理員和系統(tǒng)管理員來研究處理。 他們應(yīng)相應(yīng)地做出軟件修改報告，指明： 所需修改變動的性質(zhì)； 申請修改的優(yōu)先級； 為滿足某個維護申請報告，所需的工作量 預(yù)計修改后的狀況. 軟件修

9、改報告應(yīng)提交給變化授權(quán)人（修改負責人），經(jīng)批準后才能開始進一步安排維護工作。,19,3. 維護的事件流,20,盡管維護申請的類型不同，但都要進行同樣的技術(shù)工作。 修改軟件需求說明 修改軟件設(shè)計 設(shè)計評審 對源程序做必要的修改 單元測試 集成測試( 回歸測試) 確認測試 軟件配置評審等。,21,在每次軟件維護任務(wù)完成后進行情況評審，對以下問題做一總結(jié)：(1) 在目前情況下，設(shè)計、編碼、測試中的哪一方面可以改進?(2) 哪些維護資源應(yīng)該有但沒有?(3) 工作中主要的或次要的障礙是什么?(4) 從維護申請的類型來看是否應(yīng)當有預(yù)防性維護?情況評審對將來的維護工作如何進行會產(chǎn)生重要的影響。,22,4、維

10、護檔案記錄,程序標識； 源語句數(shù)； 機器指令條數(shù)； 使用的程序設(shè)計語言； 程序安裝的日期； 自從安裝以來程序運行的次數(shù)； 自從安裝以來程序失效的次數(shù)； 程序變動的層次和標識； 因程序變動而增加的源語句數(shù)；, 因程序變動而刪除的源語句數(shù)； 每個改動耗費的人時數(shù)； 程序改動的日期； 軟件工程師的名字； 維護要求表的標識； 維護類型； 維護開始和完成的日期； 累計用于維護的人時數(shù)； 與完成的維護相聯(lián)系的純效益。,23,5、維護評價,評價維護活動比較困難，因為缺乏可靠的數(shù)據(jù)。 如果維護的檔案記錄做得比較好，可以得出一些維護“性能”方面的度量值。 (1) 每次程序運行平均失效的次數(shù)； (2) 用于每一類

11、維護活動的總?cè)藭r數(shù)； (3) 平均每個程序、每種語言、每種維護類型所做的程序變動數(shù)； (4) 維護過程中增加或刪除一個源語句平均花費的人時數(shù)； (5) 維護每種語言平均花費的人時數(shù)； (6) 一張維護要求表的平均周轉(zhuǎn)時間； (7) 不同維護類型所占的百分比。 根據(jù)對維護工作定量度量的結(jié)果，可以做出關(guān)于開發(fā)技術(shù)、語言選擇、維護工作量規(guī)劃、資源分配及其他許多方面的決定，而且可以利用這樣的數(shù)據(jù)去分析評價維護任務(wù)。,24,程序修改的步驟及修改的副作用,在軟件維護時，必然會對源程序進行修改。 通常對源程序的修改不能無計劃地倉促上陣，為了正確、有效地修改,需要經(jīng)歷以下三個步驟。 分析和理解程序 修改程序

12、重新驗證程序,25,分析和理解程序,經(jīng)過分析，全面、準確、迅速地理解程序是決定維護成敗和質(zhì)量好壞的關(guān)鍵。在這方面，軟件的可理解性和文檔的質(zhì)量非常重要。 理解程序的功能和目標； 掌握程序的結(jié)構(gòu)信息，即從程序中細分出若干結(jié)構(gòu)成分。如程序系統(tǒng)結(jié)構(gòu)、 控制結(jié)構(gòu)、數(shù)據(jù)結(jié)構(gòu)和輸入輸出結(jié)構(gòu)等；,26,了解數(shù)據(jù)流信息，即涉及到的數(shù)據(jù)來源何處，在哪里被使用； 了解控制流信息，即執(zhí)行每條路徑的結(jié)果； 理解程序的操作(使用)要求； 為了容易地理解程序，要求自頂向下地理解現(xiàn)有源程序的程序結(jié)構(gòu)和數(shù)據(jù)結(jié)構(gòu)，為此可采用如下幾種方法：,27,1. 分析程序結(jié)構(gòu)圖(1) 搜集所有存儲該程序的文件，閱讀這些文件，記下它們包含的過

13、程名，建立一個包括這些過程名和文件名的清單；(2) 分析各個過程的源代碼，建立一個直接調(diào)用矩陣D或調(diào)用樹。若過程 i 調(diào)用過程 j，則Dij1，否則Dij0。,28,(3) 建立過程的間接調(diào)用矩陣I，即直接調(diào)用矩陣D的傳遞閉包 ID1D2D3Dn 其中，n是所包含的過程總數(shù).例如，過程 i 調(diào)用 j，j 調(diào)用 k， 則 Dij1，Djk1， Iik1。(4) 分析各個過程的接口，估計更改的復雜性。,29,2. 數(shù)據(jù)跟蹤(1) 建立各層次的程序級上的接口圖，展示各模塊或過程的調(diào)用方式和接口參數(shù)；(2) 利用數(shù)據(jù)流分析方法，對過程內(nèi)部的一些變量進行跟蹤?？色@得有關(guān)數(shù)據(jù)在過程間如何傳遞，在過程內(nèi)如何

14、處理等信息。對于判斷問題原因特別有用。在跟蹤的過程中可在源程序中間插入自己的注釋。,30,3. 控制跟蹤 控制流跟蹤可采用符號執(zhí)行或?qū)嶋H動態(tài)跟蹤的方法，了解數(shù)據(jù)如何從一個輸入源到達輸出點的。 4. 充分閱讀和使用源程序清單和文檔，分析現(xiàn)有文檔的合理性。 5. 充分使用由編譯程序或匯編程序提供的交叉引用表、符號表、以及其它有用的信息。 6. 如有可能，積極參加開發(fā)工作。,31,修改程序,對程序的修改，必須事先做出計劃，有預(yù)謀地、周密有效地實施修改。 1. 設(shè)計程序的修改計劃 程序的修改計劃要考慮人員和資源的安排。小的修改可以不需要詳細的計劃，而對于需要耗時數(shù)月的修改，就需要計劃立案。,32,在編

15、寫有關(guān)問題解決的方案時，必須充分描述修改作業(yè)的規(guī)格說明。 規(guī)格說明信息：數(shù)據(jù)修改、處理修改、作業(yè)控制語言修改、系統(tǒng)之間接口的修改等； 維護資源：新程序版本、測試數(shù)據(jù)、所需軟件、計算機時間等； 人員； 支持：紙面、計算機媒體等。,33,通常，可采用自頂向下的方法，在理解程序的基礎(chǔ)上，(1) 研究程序的各個模塊、模塊的接口、及數(shù)據(jù)庫，從全局的觀點，提出修改計劃。 (2) 依次地把要修改的、以及那些受修改影響的模塊和數(shù)據(jù)結(jié)構(gòu)分離出來。為此，要 識別受修改影響的數(shù)據(jù)； 識別使用這些數(shù)據(jù)的程序模塊；,34, 對于上面程序模塊，按是產(chǎn)生數(shù)據(jù)、修改數(shù)據(jù)、還是刪除數(shù)據(jù)進行分類； 識別對這些數(shù)據(jù)元素的外部控制信

16、息； 識別編輯和檢查這些數(shù)據(jù)元素的地方； 隔離要修改的部分；,35,(3) 詳細地分析要修改的、以及那些受變更影響的模塊和數(shù)據(jù)結(jié)構(gòu)的內(nèi)部細節(jié)，設(shè)計修改計劃，標明新邏輯及要改動的現(xiàn)有邏輯。 (4) 向用戶提供回避措施。用戶的某些業(yè)務(wù)因軟件中發(fā)生問題而中斷，為不讓系統(tǒng)長時間停止運行，需把問題局部化，在可能的范圍內(nèi)繼續(xù)開展業(yè)務(wù)。 可以采取的措施有：,36, 查找問題原因，可能情況有： 意外停機 安裝的期限到期 系統(tǒng)運行中發(fā)現(xiàn)錯誤 如果弄清了問題的原因，可通過臨時修改或改變運行控制以回避在系統(tǒng)運行時產(chǎn)生的問題。,37,2. 修改代碼，以適應(yīng)變化在修改時，要求： (1) 正確、有效地編寫修改代碼；(2)

17、 要謹慎地修改程序，盡量保持程序的風格及格式，要在程序清單上注明改動的指令；(3) 不要刪除程序語句，除非完全肯定它是無用的；(4) 不要試圖共用程序中已有的臨時變量或工作區(qū)，為了避免沖突或混淆用途，應(yīng)設(shè)置自己的變量；,38,(5) 插入錯誤檢測語句；(6) 在修改過程中做好修改的詳細記錄，消除變更中任何有害的副作用（波動效應(yīng)）； 3. 修改程序的副作用 所謂副作用是指因修改軟件而造成的錯誤或其它不希望發(fā)生的情況。副作用有三種：修改代碼的副作用、修改數(shù)據(jù)的副作用、文檔的副作用。,39,在修改源代碼時，都可能引入錯誤。例如，刪除或修改一個子程序、刪除或修改一個標號、 刪除或修改一個標識符、改變程

18、序代碼的時序關(guān)系、改變占用存儲的大小、改變邏輯運算符、修改文件的打開或關(guān)閉、改進程序的執(zhí)行效率，以及把設(shè)計上的改變翻譯成代碼的改變時，都容易引入錯誤。,(1) 修改代碼的副作用,40,(2) 修改數(shù)據(jù)的副作用,在修改數(shù)據(jù)結(jié)構(gòu)時，有可能造成軟件設(shè)計與數(shù)據(jù)結(jié)構(gòu)不匹配，因而導致軟件出錯。 數(shù)據(jù)副作用就是修改軟件信息結(jié)構(gòu)導致的結(jié)果。 容易導致設(shè)計與數(shù)據(jù)不相容的錯誤可以有： 重新定義局部的或全局的常量,41,重新定義記錄或文件的格式 增大或減小一個數(shù)組或高層數(shù)據(jù)結(jié)構(gòu)的大小 修改全局或公共數(shù)據(jù) 重新初始化控制標志或指針 重新排列輸入輸出或子程序的參數(shù) 數(shù)據(jù)副作用可以通過交叉引用表加以控制。把數(shù)據(jù)元素、記錄

19、、文件和其它結(jié)構(gòu)聯(lián)系起來。,42,(3) 文檔的副作用,對數(shù)據(jù)流、軟件結(jié)構(gòu)、 模塊邏輯或任何其它有關(guān)特性進行修改時，必須對相關(guān)技術(shù)文檔進行相應(yīng)修改。否則會導致文檔與程序功能不匹配，缺省條件改變，新錯誤信息不正確等錯誤。使得軟件文檔不能反映軟件的當前狀態(tài)。,43,如果對可執(zhí)行軟件的修改不反映在文檔里，就會產(chǎn)生文檔的副作用。 對交互輸入的順序或格式進行修改，如果沒有正確地記入文檔中，就可能引起重大的問題。 過時的文檔內(nèi)容、索引和文本可能造成沖突，引起用戶失敗和不滿。 因此，必須在軟件交付之前對整個軟件配置進行評審，以減少文檔的副作用。,44,為了控制因修改而引起的副作用，要做到：(1) 按模塊把修

20、改分組；(2) 自頂向下地安排被修改模塊的順序；(3) 每次修改一個模塊；(4) 對于每個修改了的模塊，在安排修改下一個模塊之前，要確定這個修改的副作用。可以使用交叉引用表、存儲映象表、執(zhí)行流程跟蹤等。,45,重新驗證程序,在將修改后的程序提交用戶之前，需要進行充分的確認和測試，以保證整個修改后程序的正確性。 靜態(tài)確認修改軟件，伴隨著引起新的錯誤的危險。為了能夠做出正確的判斷，驗證修改后的程序至少需要兩個人參加。要檢查：,46,(1) 修改是否涉及到規(guī)格說明? 修改結(jié)果是否符合規(guī)格說明? 有沒有歪曲規(guī)格說明?(2) 程序的修改是否足以修正軟件中的問題? 源程序代碼有無邏輯錯誤? 修改時有無修補

21、失誤?(3) 修改部分對其它部分有無不良影響(副作用)?對軟件進行修改，常常會引發(fā)別的問題，有必要檢查修改的影響范圍。,47,計算機確認在進行了以上確認的基礎(chǔ)上，用計算機對修改程序進行確認測試：(1) 確認測試順序：先對修改部分進行測試，然后隔離修改部分，測試程序的未修改部分，最后再把它們集成起來進行測試。這種測試稱為回歸測試。 (2) 準備標準的測試用例。(3) 充分利用軟件工具幫助重新驗證過程。,48,(4) 在重新確認過程中，需邀請用戶參加。 維護后的驗收在交付新軟件之前，維護主管部門要檢驗：(1) 全部文檔是否完備，并已更新；(2) 所有測試用例和測試結(jié)果已經(jīng)正確記載；(3) 記錄軟件

22、配置所有副本的工作已經(jīng)完成；(4) 維護工序和責任已經(jīng)確定。,49,從維護角度來看所需測試種類,(1) 對修改事務(wù)的測試； (2) 對修改程序的測試； (3) 操作過程的測試； (4) 應(yīng)用系統(tǒng)運用過程的測試； (5) 系統(tǒng)各部分之間接口的測試； (6) 作業(yè)控制語言的測試； (7) 與系統(tǒng)軟件接口的測試；,50,(8) 軟件系統(tǒng)之間接口的測試； (9) 安全性測試； (10) 后備恢復過程的測試。,51,8.4 軟件的可維護性,許多軟件的維護十分困難，原因在于這些軟件的文檔不全、質(zhì)量差、開發(fā)過程不注意采用好的方法，忽視程序設(shè)計風格等。 許多維護要求并不是因為程序中出錯而提出的，而是為適應(yīng)環(huán)境

23、變化或需求變化而提出的。 為了使得軟件能夠易于維護，必須考慮使軟件具有可維護性。 軟件可維護性是指糾正軟件系統(tǒng)出現(xiàn)的錯誤和缺陷，以及為滿足新的要求進行修改、擴充或壓縮的容易程度。,52,8.4.1 決定軟件可維護性的因素,1. 可理解性 表現(xiàn)為外來讀者理解軟件的結(jié)構(gòu)、功能、接口和內(nèi)部處理過程的難易程度。 模塊化（模塊結(jié)構(gòu)良好，高內(nèi)聚，松耦合）、詳細的設(shè)計文檔、結(jié)構(gòu)化設(shè)計、程序內(nèi)部的文檔和良好的高級程序設(shè)計語言等等，都對提高軟件的可理解性有重要貢獻。 2. 可測試性 診斷和測試的容易程度取決于軟件容易理解的程度。軟件結(jié)構(gòu)、可用的測試工具和調(diào)試工具，以及以前設(shè)計的測試過程也都是非常重要的,53,8

24、.4.1 決定軟件可維護性的因素,3. 可修改性(和第五章設(shè)計原理和啟發(fā)規(guī)則直接有關(guān)，p100-) 4. 可移植性 把程序從一種計算機環(huán)境(硬件配置和操作系統(tǒng))轉(zhuǎn)移到 另一種計算環(huán)境的難易程度. 5. 可重用性 指同一事物不做修改或稍加改動就在不同的環(huán)境中多次 重復使用.,54,8.4.2 文 檔,文檔是影響軟件可維護性的決定因素。往往文檔比程序代碼更重要。 軟件系統(tǒng)的文檔可以分為用戶文檔和系統(tǒng)文檔兩類。 - 用戶文檔主要描述系統(tǒng)功能和使用 方法，并不關(guān)心這些功能是怎樣實現(xiàn)的； - 系統(tǒng)文檔描述系統(tǒng)設(shè)計、實現(xiàn)和測試等各方面的內(nèi)容。,55,軟件文檔應(yīng)該滿足下述要求： (1) 必須描述如何使用這個

25、系統(tǒng)，沒有這種描述時即使是最簡單的系統(tǒng)也無法使用； (2) 必須描述怎樣安裝和管理這個系統(tǒng)； (3) 必須描述系統(tǒng)需求和設(shè)計； (4) 必須描述系統(tǒng)的實現(xiàn)和測試，以便使系統(tǒng)成為可維護的。,56,1. 用戶文檔 用戶文檔是用戶了解系統(tǒng)的第一步，它應(yīng)該能使用戶獲得對系統(tǒng)的準確的初步印象。文檔的結(jié)構(gòu)方式應(yīng)該使用戶能夠方便地根據(jù)需要閱讀有關(guān)的內(nèi)容。 用戶文檔至少應(yīng)該包括下述5方面的內(nèi)容： (1) 功能描述； (2) 安裝文檔； (3) 使用手冊； (4) 參考手冊； (5) 操作員指南(如果需要有系統(tǒng)操作員的話) 。 上述內(nèi)容可以分別作為獨立的文檔， 也可以作為一個文檔的不同分冊， 具體做法應(yīng)該由系統(tǒng)

26、規(guī)模決定。,57,2. 系統(tǒng)文檔 - 所謂系統(tǒng)文檔指從問題定義、需求說明到驗收測試計劃這樣一系列和系統(tǒng)實現(xiàn)有關(guān)的文檔。 - 描述系統(tǒng)設(shè)計、實現(xiàn)和測試的文檔對于理解程序和維護程序來說是極端重要的。 - 和用戶文檔類似，系統(tǒng)文檔的結(jié)構(gòu)也應(yīng)該能把讀者從對系統(tǒng)概貌的了解，引導到對系統(tǒng)每個方面每個特點的更形式化更具體的認識。,58,8.4.3 提高可維護性的方法,建立明確的軟件質(zhì)量目標和優(yōu)先級 使用提高軟件質(zhì)量的技術(shù)和工具 進行明確的質(zhì)量保證審查 選擇可維護的程序設(shè)計語言 改進程序的文檔,59,8.4.4 可維護性復審,在軟件工程過程的每一個階段都應(yīng)該考慮并努力提高軟件的可維護性，在每個階段結(jié)束前的技術(shù)審查和管理復審中，應(yīng)該著重對可維護性進行復審。,60,在完成了每項維護工作之后，都應(yīng)該對軟件維護本身進行仔細認真的復審。 - 維護應(yīng)該針對整個軟件配置，不應(yīng)該只修改源程序代碼。當對源程序代碼的修改沒有反映在設(shè)計文檔或用戶手冊中時，就會產(chǎn)生嚴重的后果。 - 每當對數(shù)據(jù)、軟件結(jié)構(gòu)、模