第12章軟件維護

1、第5部分 軟件維護與軟件管理第第12章章 軟件維護軟件維護 12.1 軟件維護的概念 軟件維護的定義軟件維護的定義 軟件維護軟件維護是指在軟件運行是指在軟件運行/維護階段對軟件產(chǎn)品所進行的修維護階段對軟件產(chǎn)品所進行的修改就是所謂的維護。根據(jù)維護工作的性質，軟件維護的活動改就是所謂的維護。根據(jù)維護工作的性質，軟件維護的活動可以分為以下可以分為以下4種類型。種類型。1改正性維護改正性維護 改正性維護改正性維護（corrective maintenance）為了識別和糾正）為了識別和糾正軟件錯誤、改正軟件性能上的缺陷、排除實施中的誤使軟件錯誤、改正軟件性能上的缺陷、排除實施中的誤使用，應進行的診斷和

2、改正錯誤的過程。例如，改正性維護用，應進行的診斷和改正錯誤的過程。例如，改正性維護可以是改正原來程序中開關使用的錯誤；解決開發(fā)時未能可以是改正原來程序中開關使用的錯誤；解決開發(fā)時未能測試各種可能情況帶來的問題等。測試各種可能情況帶來的問題等。 2適應性維護適應性維護 隨著信息技術的飛速發(fā)展，軟件運行的外部環(huán)境（新的隨著信息技術的飛速發(fā)展，軟件運行的外部環(huán)境（新的硬、軟件配置）或數(shù)據(jù)環(huán)境（數(shù)據(jù)庫、數(shù)據(jù)格式、數(shù)據(jù)輸入硬、軟件配置）或數(shù)據(jù)環(huán)境（數(shù)據(jù)庫、數(shù)據(jù)格式、數(shù)據(jù)輸入/輸出方式、數(shù)據(jù)存儲介質）可能發(fā)生變化，為了使軟件適輸出方式、數(shù)據(jù)存儲介質）可能發(fā)生變化，為了使軟件適應這種變化，而修改軟件的過程叫

3、做應這種變化，而修改軟件的過程叫做適應性維護適應性維護（adaptive maintenance）。例如，需要對已運行的軟件進行改造，以）。例如，需要對已運行的軟件進行改造，以適應網(wǎng)絡環(huán)境或已升級改版的操作系統(tǒng)要求。適應網(wǎng)絡環(huán)境或已升級改版的操作系統(tǒng)要求。3完善性維護完善性維護 為了滿足新的功能與性能要求，需要修改或再開發(fā)軟件，為了滿足新的功能與性能要求，需要修改或再開發(fā)軟件，以擴充軟件功能、增強軟件性能、改進加工效率、提高軟件以擴充軟件功能、增強軟件性能、改進加工效率、提高軟件12.1 軟件維護的概念的可維護性。這種情況下進行的維護活動叫做的可維護性。這種情況下進行的維護活動叫做完善性維護完

4、善性維護（perfective maintenance）。例如，完善性維護可能是修）。例如，完善性維護可能是修改一個計算工資的程序，使其增加新的扣除項目；縮短系統(tǒng)改一個計算工資的程序，使其增加新的扣除項目；縮短系統(tǒng)的應答時間，使其達到特定的要求等。的應答時間，使其達到特定的要求等。4預防性維護預防性維護 預防性維護預防性維護（preventive maintenance）是指把今天的）是指把今天的方法學用于昨天的系統(tǒng)以滿足明天的需要。也就是說，采方法學用于昨天的系統(tǒng)以滿足明天的需要。也就是說，采用先進的軟件工程方法對需要維護的軟件或軟件中的某一部用先進的軟件工程方法對需要維護的軟件或軟件中的某

5、一部分（重新）進行設計、編碼和測試。分（重新）進行設計、編碼和測試。12.1 軟件維護的概念 以上介紹的幾類維護占總維護工作量的比例以及維護在以上介紹的幾類維護占總維護工作量的比例以及維護在軟件生存期成本所占比例如下圖所示軟件生存期成本所占比例如下圖所示。 在整個軟件維護階段花費的全部工作量中，預防性維護在整個軟件維護階段花費的全部工作量中，預防性維護只占很小的比例，而完善性維護占了幾乎一半的工作量。只占很小的比例，而完善性維護占了幾乎一半的工作量。軟件維護活動花費的工作量占整個生存期工作量的軟件維護活動花費的工作量占整個生存期工作量的70%以以12.1 軟件維護的概念上（工作量的比例直接反映

6、了成本的比例）上（工作量的比例直接反映了成本的比例） ，這是由于在，這是由于在漫長的軟件運行過程中需要不斷對軟件進行修改，以使其漫長的軟件運行過程中需要不斷對軟件進行修改，以使其進一步完善、改正新發(fā)現(xiàn)的錯誤、適應新的環(huán)境和用戶新進一步完善、改正新發(fā)現(xiàn)的錯誤、適應新的環(huán)境和用戶新的需求，這些修改需要花費很多精力和時間，而且有時修的需求，這些修改需要花費很多精力和時間，而且有時修改不正確，還會引入新的錯誤。同時，軟件維護技術不像改不正確，還會引入新的錯誤。同時，軟件維護技術不像開發(fā)技術那樣成熟、規(guī)范化，自然消耗工作量就比較多。開發(fā)技術那樣成熟、規(guī)范化，自然消耗工作量就比較多。12.1 軟件維護的概

7、念 在軟件維護中，影響維護工作量的因素主要有以下在軟件維護中，影響維護工作量的因素主要有以下6種種:（1）系統(tǒng)規(guī)模。）系統(tǒng)規(guī)模。（2）程序設計語言。）程序設計語言。（3）系統(tǒng)年齡大小。）系統(tǒng)年齡大小。（4）數(shù)據(jù)庫技術的應用水平。）數(shù)據(jù)庫技術的應用水平。（5）所采用的軟件開發(fā)技術及軟件開發(fā)工程化的程度。）所采用的軟件開發(fā)技術及軟件開發(fā)工程化的程度。（6）其他：如應用的類型、數(shù)學模型、任務的難度、）其他：如應用的類型、數(shù)學模型、任務的難度、IF嵌嵌 套深度、索引或下標數(shù)等，對維護工作量都有影響。套深度、索引或下標數(shù)等，對維護工作量都有影響。 影響維護工作量的因素影響維護工作量的因素 12.1 軟件

8、維護的概念 根據(jù)影響軟件維護工作量的各種因素，針對根據(jù)影響軟件維護工作量的各種因素，針對3種典型維種典型維護，護，James Martin等提出了一些策略，以控制維護成本。等提出了一些策略，以控制維護成本。1改正性維護改正性維護 應用一些諸如數(shù)據(jù)庫管理系統(tǒng)、軟件開發(fā)環(huán)境、程序自應用一些諸如數(shù)據(jù)庫管理系統(tǒng)、軟件開發(fā)環(huán)境、程序自動生成系統(tǒng)和高級（第四代）語言等新技術可大大提高可動生成系統(tǒng)和高級（第四代）語言等新技術可大大提高可靠性，并減少進行改正性維護的需要。此外，還可考慮利靠性，并減少進行改正性維護的需要。此外，還可考慮利用應用軟件包、防錯性程序設計、通過周期性維護審查等用應用軟件包、防錯性程序

9、設計、通過周期性維護審查等策略。策略。 軟件維護的策略軟件維護的策略 12.1 軟件維護的概念2適應性維護適應性維護 這一類的維護不可避免，但可以采用以下策略加以控制。這一類的維護不可避免，但可以采用以下策略加以控制。（1）在配置管理時，把硬件、操作系統(tǒng)和其他相關環(huán)境因）在配置管理時，把硬件、操作系統(tǒng)和其他相關環(huán)境因素的可能變化考慮在內(nèi)，可以減少某些適應性維護的工作素的可能變化考慮在內(nèi)，可以減少某些適應性維護的工作量。量。（2）把與硬件、操作系統(tǒng)，以及其他外圍設備有關的程序）把與硬件、操作系統(tǒng)，以及其他外圍設備有關的程序歸到特定的程序模塊中。可把因環(huán)境變化而必須修改的程序歸到特定的程序模塊中。

10、可把因環(huán)境變化而必須修改的程序局部于某些程序模塊之中。局部于某些程序模塊之中。（3）使用內(nèi)部程序列表、外部文件，以及處理的例行程序）使用內(nèi)部程序列表、外部文件，以及處理的例行程序包，可為維護時修改程序提供方便。包，可為維護時修改程序提供方便。12.1 軟件維護的概念（4）使用面向對象技術，增強軟件系統(tǒng)的穩(wěn)定性，易于修）使用面向對象技術，增強軟件系統(tǒng)的穩(wěn)定性，易于修改和移植。改和移植。3完善性維護完善性維護 利用前兩類維護中列舉的方法，也可以減少這一類維利用前兩類維護中列舉的方法，也可以減少這一類維護。特別是數(shù)據(jù)庫管理系統(tǒng)、程序生成器、應用軟件包，護。特別是數(shù)據(jù)庫管理系統(tǒng)、程序生成器、應用軟件包

11、，可減少系統(tǒng)或程序員的維護工作量?？蓽p少系統(tǒng)或程序員的維護工作量。 此外，建立軟件系統(tǒng)的原型，把它在實際系統(tǒng)開發(fā)之前此外，建立軟件系統(tǒng)的原型，把它在實際系統(tǒng)開發(fā)之前提供給用戶。用戶通過研究原型，進一步完善他們的功能提供給用戶。用戶通過研究原型，進一步完善他們的功能要求，可以減少以后完善性維護的需要。要求，可以減少以后完善性維護的需要。12.1 軟件維護的概念 為了有效地進行軟件維護，應事先就開始做組織工作，為了有效地進行軟件維護，應事先就開始做組織工作，確定實施維護的機構，明確提出維護申請報告的過程及評確定實施維護的機構，明確提出維護申請報告的過程及評價的過程；為每一個維護申請規(guī)定標準的處理步

12、驟；還必價的過程；為每一個維護申請規(guī)定標準的處理步驟；還必須建立維護活動的記錄制度以及規(guī)定評價和評審的標準。須建立維護活動的記錄制度以及規(guī)定評價和評審的標準。 12.2 軟件維護活動 軟件維護申請報告軟件維護申請報告 所有軟件維護申請應按規(guī)定的方式提出。軟件維護組織所有軟件維護申請應按規(guī)定的方式提出。軟件維護組織通常提供維護申請報告（通常提供維護申請報告（maintenance request form，MRF），或稱軟件問題報告，由），或稱軟件問題報告，由申請維護的用戶填寫申請維護的用戶填寫。如。如果遇到一個錯誤，用戶必須完整地說明產(chǎn)生錯誤的情況，果遇到一個錯誤，用戶必須完整地說明產(chǎn)生錯誤的

13、情況，包括輸入數(shù)據(jù)、錯誤清單以及其他有關材料。如果申請的包括輸入數(shù)據(jù)、錯誤清單以及其他有關材料。如果申請的是適應性維護或完善性維護，用戶必須提出一份修改說明是適應性維護或完善性維護，用戶必須提出一份修改說明書，列出所有希望的修改。維護申請報告將書，列出所有希望的修改。維護申請報告將由維護管理員和由維護管理員和系統(tǒng)監(jiān)督員來研究處理系統(tǒng)監(jiān)督員來研究處理。 維護申請報告是由軟件組織外部提交的文檔，它是計劃維維護申請報告是由軟件組織外部提交的文檔，它是計劃維護工作的基礎。軟件組織內(nèi)部應相應地做出軟件修改報告護工作的基礎。軟件組織內(nèi)部應相應地做出軟件修改報告（software change report

14、，SCR），指明：），指明： 所需修改變動的性質；所需修改變動的性質； 申請修改的優(yōu)先級；申請修改的優(yōu)先級； 為滿足某個維護申請報告，所需的工作量；為滿足某個維護申請報告，所需的工作量； 預計修改后的狀況。預計修改后的狀況。 軟件修改報告應提交修改負責人，經(jīng)批準后才能開始進一軟件修改報告應提交修改負責人，經(jīng)批準后才能開始進一步安排維護工作。步安排維護工作。12.2 軟件維護活動 軟件維護工作流程如下圖所示。軟件維護工作流程如下圖所示。12.2 軟件維護活動 軟件維護工作流程軟件維護工作流程 第一步是先確認維護要求，然后由維護組織管理員確認第一步是先確認維護要求，然后由維護組織管理員確認維護類型

15、。維護類型。對于改正性維護申請對于改正性維護申請，如果存在嚴重的錯誤，如果存在嚴重的錯誤，則必須安排人員，在系統(tǒng)監(jiān)督員的指導下，進行問題分則必須安排人員，在系統(tǒng)監(jiān)督員的指導下，進行問題分析，尋找錯誤發(fā)生的原因，進行析，尋找錯誤發(fā)生的原因，進行“救火救火”性的緊急維護性的緊急維護；對對于不嚴重的錯誤，可根據(jù)任務和人員情況，視輕重緩急進于不嚴重的錯誤，可根據(jù)任務和人員情況，視輕重緩急進行排隊，統(tǒng)一安排時間。所謂行排隊，統(tǒng)一安排時間。所謂“救火救火”式的緊急維護式的緊急維護，是，是指指對非常嚴重的錯誤進行緊急修改，暫不再顧及正常的維護對非常嚴重的錯誤進行緊急修改，暫不再顧及正常的維護控制，不必考慮評

16、價可能發(fā)生的副作用。在維護完成、交控制，不必考慮評價可能發(fā)生的副作用。在維護完成、交付用戶之后再去做這些工作。付用戶之后再去做這些工作。12.2 軟件維護活動 對于適應性維護和完善性維護申請對于適應性維護和完善性維護申請，需要先確定每項申請，需要先確定每項申請的優(yōu)先次序。若某項申請的優(yōu)先級非常高，就可立即開始維的優(yōu)先次序。若某項申請的優(yōu)先級非常高，就可立即開始維護工作；否則，維護申請和其他的開發(fā)工作一樣，進行排護工作；否則，維護申請和其他的開發(fā)工作一樣，進行排隊，統(tǒng)一安排時間。隊，統(tǒng)一安排時間。 盡管維護申請的類型不同，但都要進行同樣的技術工作。盡管維護申請的類型不同，但都要進行同樣的技術工作

17、。這些工作這些工作包括包括：修改軟件需求說明、修改軟件設計、設計評：修改軟件需求說明、修改軟件設計、設計評審、對源程序做必要的修改、單元測試、集成測試（回歸測審、對源程序做必要的修改、單元測試、集成測試（回歸測試）、確認測試、軟件配置評審等。試）、確認測試、軟件配置評審等。 在每次軟件維護任務完成后，最好進行一次情況評審，對在每次軟件維護任務完成后，最好進行一次情況評審，對以下問題做一總結：以下問題做一總結：12.2 軟件維護活動l 在目前情況下，設計、編碼、測試中的哪一方面可以改在目前情況下，設計、編碼、測試中的哪一方面可以改 進？進？l 哪些維護資源應該有，但沒有？哪些維護資源應該有，但沒

18、有？l 工作中主要的或次要的障礙是什么？工作中主要的或次要的障礙是什么？l 從維護申請的類型來看是否應當有預防性維護？情況評從維護申請的類型來看是否應當有預防性維護？情況評 審對將來的維護工作如何進行會產(chǎn)生重要的影響，并可審對將來的維護工作如何進行會產(chǎn)生重要的影響，并可為軟件機構的有效管理提供重要的反饋信息。為軟件機構的有效管理提供重要的反饋信息。 12.2 軟件維護活動12.2 軟件維護活動 維護檔案記錄維護檔案記錄 為了估計軟件維護的有效程度，確定軟件產(chǎn)品的質量，同為了估計軟件維護的有效程度，確定軟件產(chǎn)品的質量，同時確定維護的實際開銷，需要在維護的過程中做好維護檔案時確定維護的實際開銷，需

19、要在維護的過程中做好維護檔案記錄。其記錄。其內(nèi)容包括內(nèi)容包括程序名稱、源程序語句條數(shù)、機器代碼指程序名稱、源程序語句條數(shù)、機器代碼指令條數(shù)、所用的程序設計語言、程序安裝的日期、程序安裝令條數(shù)、所用的程序設計語言、程序安裝的日期、程序安裝后的運行次數(shù)、與程序安裝后運行次數(shù)有關的處理故障次數(shù)、后的運行次數(shù)、與程序安裝后運行次數(shù)有關的處理故障次數(shù)、程序改變的層次及名稱、修改程序所增加的源程序語句條數(shù)、程序改變的層次及名稱、修改程序所增加的源程序語句條數(shù)、修改程序所減少的源程序語句條數(shù)、每次修改所付出的修改程序所減少的源程序語句條數(shù)、每次修改所付出的“人人時時”數(shù)、修改程序的日期、軟件維護人員的姓名、

20、維護申請數(shù)、修改程序的日期、軟件維護人員的姓名、維護申請報告的名稱、維護類型、維護開始時間和維護結束時間、花報告的名稱、維護類型、維護開始時間和維護結束時間、花費在維護上的累計費在維護上的累計“人時人時”數(shù)、維護工作的凈收益等。對每數(shù)、維護工作的凈收益等。對每項維護任務都應該收集上述數(shù)據(jù)。項維護任務都應該收集上述數(shù)據(jù)。 評價維護活動可評價維護活動可參考的度量值參考的度量值有：有： 每次程序運行時的平均出錯次數(shù)；每次程序運行時的平均出錯次數(shù)； 花費在每類維護上的總花費在每類維護上的總“人時人時”數(shù)；數(shù)； 每個程序、每種語言、每種維護類型的程序平均修改次每個程序、每種語言、每種維護類型的程序平均修

21、改次 數(shù)；數(shù)； 因為維護，增加或刪除每個源程序語句所花費的平均因為維護，增加或刪除每個源程序語句所花費的平均“人人 時時”數(shù)；數(shù)； 用于每種語言的平均用于每種語言的平均“人時人時”數(shù)；數(shù)； 維護申請報告的平均處理時間；維護申請報告的平均處理時間； 各類維護申請的百分比。各類維護申請的百分比。 12.2 軟件維護活動 維護評價維護評價 為了正確、有效地進行程序修改，需要經(jīng)歷為了正確、有效地進行程序修改，需要經(jīng)歷3個步驟個步驟：分分析和理解程序析和理解程序、實施修改實施修改以及以及重新驗證程序重新驗證程序。12.3 程序修改的步驟及修改的副作用 分析和理解程序分析和理解程序 經(jīng)過分析，全面、準確、

22、迅速地理解程序是決定維護成經(jīng)過分析，全面、準確、迅速地理解程序是決定維護成敗和質量好壞的關鍵。在這方面，軟件的可理解性和文檔的敗和質量好壞的關鍵。在這方面，軟件的可理解性和文檔的質量非常重要。為此必須：質量非常重要。為此必須：（1）研究程序的使用環(huán)境及有關資料，盡可能得到更多的）研究程序的使用環(huán)境及有關資料，盡可能得到更多的 背景信息；背景信息；（2）理解程序的功能和目標；）理解程序的功能和目標；（3）掌握程序的結構信息，即從程序中細分出若干結構成）掌握程序的結構信息，即從程序中細分出若干結構成 分，如程序系統(tǒng)結構、控制結構、數(shù)據(jù)結構和輸入分，如程序系統(tǒng)結構、控制結構、數(shù)據(jù)結構和輸入/輸輸 出

23、結構等；出結構等； （4）了解數(shù)據(jù)流信息，即所涉及的數(shù)據(jù)來自何處，在哪里）了解數(shù)據(jù)流信息，即所涉及的數(shù)據(jù)來自何處，在哪里 被使用；被使用；（5）了解控制流信息，即執(zhí)行每條路徑的結果；）了解控制流信息，即執(zhí)行每條路徑的結果；（6）如果設計存在，則可利用它們來幫助畫出結構圖和高）如果設計存在，則可利用它們來幫助畫出結構圖和高 層流程圖；層流程圖；（7）理解程序的操作（使用）要求。）理解程序的操作（使用）要求。12.3 程序修改的步驟及修改的副作用 為了容易地理解程序，要求自頂向下地理解現(xiàn)有源程序的為了容易地理解程序，要求自頂向下地理解現(xiàn)有源程序的程序結構和數(shù)據(jù)結構，為此可采用如下幾種方法。程序結構

24、和數(shù)據(jù)結構，為此可采用如下幾種方法。（1）分析程序結構圖。）分析程序結構圖。（2）數(shù)據(jù)跟蹤。）數(shù)據(jù)跟蹤。（3）控制跟蹤?？刹捎梅枅?zhí)行或實際動態(tài)跟蹤的方法，）控制跟蹤?？刹捎梅枅?zhí)行或實際動態(tài)跟蹤的方法， 了解數(shù)據(jù)是如何從一個輸入源到達輸出點的。了解數(shù)據(jù)是如何從一個輸入源到達輸出點的。（4）在分析的過程中，應充分閱讀和使用源程序清單和文）在分析的過程中，應充分閱讀和使用源程序清單和文 檔，分析現(xiàn)有文檔的合理性。檔，分析現(xiàn)有文檔的合理性。（5）充分使用由編譯程序或匯編程序提供的交叉引用表、）充分使用由編譯程序或匯編程序提供的交叉引用表、 符號表，以及其他有用的信息。符號表，以及其他有用的信息。（

25、6）如有可能，爭取參加開發(fā)工作。）如有可能，爭取參加開發(fā)工作。 12.3 程序修改的步驟及修改的副作用 對程序的修改，必須事先做出計劃，有準備地、周密有效對程序的修改，必須事先做出計劃，有準備地、周密有效地實施修改。地實施修改。1設計程序的修改計劃設計程序的修改計劃 程序的修改計劃要考慮人員和資源的安排。程序的修改計劃要考慮人員和資源的安排。修改計劃的內(nèi)修改計劃的內(nèi)容容主要包括以下幾項：主要包括以下幾項：（1）規(guī)格說明信息規(guī)格說明信息：數(shù)據(jù)修改、處理修改、作業(yè)控制語言：數(shù)據(jù)修改、處理修改、作業(yè)控制語言 修改、系統(tǒng)之間接口的修改等。修改、系統(tǒng)之間接口的修改等。（2）維護資源維護資源：新程序版本、

26、測試數(shù)據(jù)、所需的軟件系：新程序版本、測試數(shù)據(jù)、所需的軟件系 統(tǒng)、計算機時間等。統(tǒng)、計算機時間等。12.3 程序修改的步驟及修改的副作用 修改程序修改程序 （3）人員人員：程序員、用戶相關人員、技術支持人員、廠家：程序員、用戶相關人員、技術支持人員、廠家 聯(lián)系人、數(shù)據(jù)錄入員等。聯(lián)系人、數(shù)據(jù)錄入員等。（4）提供提供：紙質、計算機媒體等。：紙質、計算機媒體等。 針對以上每一項，要說明必要性、從何處著手、是否接針對以上每一項，要說明必要性、從何處著手、是否接受、日期等。通常，可采用自頂向下的方法，在理解程序的受、日期等。通常，可采用自頂向下的方法，在理解程序的基礎上做如下工作：基礎上做如下工作：（1）

27、研究程序的各個模塊、模塊的接口及數(shù)據(jù)庫，從全局）研究程序的各個模塊、模塊的接口及數(shù)據(jù)庫，從全局 的觀點提出修改計劃。的觀點提出修改計劃。（2）依次把要修改的、以及那些受修改影響的模塊和數(shù)據(jù)）依次把要修改的、以及那些受修改影響的模塊和數(shù)據(jù) 結構分離出來。結構分離出來。 12.3 程序修改的步驟及修改的副作用（3）詳細地分析要修改的，以及那些受變更影響的模塊和）詳細地分析要修改的，以及那些受變更影響的模塊和 數(shù)據(jù)結構的內(nèi)部細節(jié)，設計修改計劃，標明新邏輯及數(shù)據(jù)結構的內(nèi)部細節(jié)，設計修改計劃，標明新邏輯及 要改動的現(xiàn)有邏輯。要改動的現(xiàn)有邏輯。（4）向用戶提供回避措施。用戶的某些業(yè)務因軟件中發(fā)生）向用戶提

28、供回避措施。用戶的某些業(yè)務因軟件中發(fā)生 問題而中斷，為不讓系統(tǒng)長時間停止運行，需把問題問題而中斷，為不讓系統(tǒng)長時間停止運行，需把問題 局部化，在可能的范圍內(nèi)繼續(xù)開展業(yè)務。局部化，在可能的范圍內(nèi)繼續(xù)開展業(yè)務。2修改代碼，以適應變化修改代碼，以適應變化 修改時，要求：修改時，要求：（1）正確、有效地編寫修改代碼；）正確、有效地編寫修改代碼；（2）要謹慎地修改程序，盡量保持程序的風格及格式，要）要謹慎地修改程序，盡量保持程序的風格及格式，要 12.3 程序修改的步驟及修改的副作用 在程序清單上注明改動的指令；在程序清單上注明改動的指令；（3）不要匆忙刪除程序語句，除非完全肯定它是無用的；）不要匆忙刪

29、除程序語句，除非完全肯定它是無用的；（4）不要試圖共用程序中已有的臨時變量或工作區(qū)，為了）不要試圖共用程序中已有的臨時變量或工作區(qū)，為了 避免沖突或混淆用途，應自行設置自己的變量；避免沖突或混淆用途，應自行設置自己的變量；（5）插入錯誤檢測語句；）插入錯誤檢測語句；（6）保持詳細的維護活動和維護結果記錄；）保持詳細的維護活動和維護結果記錄；（7）如果程序結構混亂，修改受到干擾，可拋棄程序重新）如果程序結構混亂，修改受到干擾，可拋棄程序重新 編寫。編寫。 12.3 程序修改的步驟及修改的副作用 所謂所謂程序修改的副作用程序修改的副作用是指因修改軟件而造成的錯誤是指因修改軟件而造成的錯誤或其他不希

30、望發(fā)生的情況，有以下或其他不希望發(fā)生的情況，有以下3種副作用：種副作用：1修改代碼的副作用修改代碼的副作用 在使用程序設計語言修改源代碼時，都可能引入新的在使用程序設計語言修改源代碼時，都可能引入新的錯誤。例如，刪除或修改一個子程序、刪除或修改一個標錯誤。例如，刪除或修改一個子程序、刪除或修改一個標號、刪除或修改一個標識符、改變程序代碼的時序關系、號、刪除或修改一個標識符、改變程序代碼的時序關系、改變占用存儲的大小、改變邏輯運算符、修改文件的打開改變占用存儲的大小、改變邏輯運算符、修改文件的打開或關閉、改進程序的執(zhí)行效率，以及把設計上的改變翻譯或關閉、改進程序的執(zhí)行效率，以及把設計上的改變翻譯

31、成代碼的改變、為邊界條件的邏輯測試做出改變時，都容成代碼的改變、為邊界條件的邏輯測試做出改變時，都容易引入錯誤。易引入錯誤。 12.3 程序修改的步驟及修改的副作用 修改程序的副作用及其控制修改程序的副作用及其控制 2修改數(shù)據(jù)的副作用修改數(shù)據(jù)的副作用 在修改數(shù)據(jù)結構時，有可能造成軟件設計與數(shù)據(jù)結構不匹在修改數(shù)據(jù)結構時，有可能造成軟件設計與數(shù)據(jù)結構不匹配，因而導致軟件出錯。配，因而導致軟件出錯。修改數(shù)據(jù)的副作用修改數(shù)據(jù)的副作用是修改軟件信息是修改軟件信息結構導致的結果。例如，在重新定義局部的或全局的常量、結構導致的結果。例如，在重新定義局部的或全局的常量、重新定義記錄或文件的格式、增大或減小一個

32、數(shù)組或高層數(shù)重新定義記錄或文件的格式、增大或減小一個數(shù)組或高層數(shù)據(jù)結構的大小、修改全局或公共數(shù)據(jù)、重新初始化控制標志據(jù)結構的大小、修改全局或公共數(shù)據(jù)、重新初始化控制標志或指針、重新排列輸入或指針、重新排列輸入/輸出或子程序的參數(shù)時，容易導致輸出或子程序的參數(shù)時，容易導致設計與數(shù)據(jù)不相容的錯誤。數(shù)據(jù)副作用可以通過詳細的設計設計與數(shù)據(jù)不相容的錯誤。數(shù)據(jù)副作用可以通過詳細的設計文檔加以控制。文檔加以控制。12.3 程序修改的步驟及修改的副作用3修改文檔的副作用修改文檔的副作用 對數(shù)據(jù)流、軟件結構、模塊邏輯或任何其他有關特性進對數(shù)據(jù)流、軟件結構、模塊邏輯或任何其他有關特性進行修改時，必須對相關技術文檔

33、進行相應修改。如果對可行修改時，必須對相關技術文檔進行相應修改。如果對可執(zhí)行軟件的修改不反映在文檔里，會產(chǎn)生執(zhí)行軟件的修改不反映在文檔里，會產(chǎn)生文檔的副作用文檔的副作用。例如，對交互輸入的順序或格式進行修改，如果沒有正確例如，對交互輸入的順序或格式進行修改，如果沒有正確地記入文檔中，可能引起重大的問題。過時的文檔內(nèi)容、地記入文檔中，可能引起重大的問題。過時的文檔內(nèi)容、索引和文本可能造成沖突，引起用戶業(yè)務的失敗和不滿。索引和文本可能造成沖突，引起用戶業(yè)務的失敗和不滿。因此，必須在軟件交付之前對整個軟件配置進行評審，以因此，必須在軟件交付之前對整個軟件配置進行評審，以減少文檔的副作用。減少文檔的副

34、作用。12.3 程序修改的步驟及修改的副作用 為了控制因修改而引起的副作用，要做到：為了控制因修改而引起的副作用，要做到：（1）按模塊把修改分組；）按模塊把修改分組；（2）自頂向下地安排被修改模塊的順序；）自頂向下地安排被修改模塊的順序；（3）每次修改一個模塊；）每次修改一個模塊；（4）對于每個修改了的模塊，在安排修改下一個模塊之）對于每個修改了的模塊，在安排修改下一個模塊之 前，要確定這個修改的副作用，可以使用交叉引用前，要確定這個修改的副作用，可以使用交叉引用 表、存儲映象表、執(zhí)行流程跟蹤等。表、存儲映象表、執(zhí)行流程跟蹤等。12.3 程序修改的步驟及修改的副作用 重新驗證程序重新驗證程序

35、12.3 程序修改的步驟及修改的副作用（3 3）修改部分對其他部分有無不良影響（副作用）？）修改部分對其他部分有無不良影響（副作用）？ 對軟件進行修改，常常會引發(fā)別的問題，因此，有必要對軟件進行修改，常常會引發(fā)別的問題，因此，有必要 檢查修改的影響范圍。檢查修改的影響范圍。2確認測試確認測試 在充分進行了以上確認的基礎上，要用計算機對修改程在充分進行了以上確認的基礎上，要用計算機對修改程 序進行確認測試。序進行確認測試。（1 1）確認測試順序：先對修改部分進行測試，然后隔離修）確認測試順序：先對修改部分進行測試，然后隔離修 改部分，測試程序的未修改部分，最后再把它們集成起改部分，測試程序的未修

36、改部分，最后再把它們集成起 來進行測試。這種測試稱為來進行測試。這種測試稱為回歸測試回歸測試。（2 2）準備標準的測試用例。）準備標準的測試用例。12.3 程序修改的步驟及修改的副作用（3）充分利用軟件工具幫助重新驗證過程。）充分利用軟件工具幫助重新驗證過程。（4）在重新確認過程中，需邀請用戶參加。）在重新確認過程中，需邀請用戶參加。3維護后的驗收維護后的驗收 在交付新軟件之前，維護主管部門要檢驗：在交付新軟件之前，維護主管部門要檢驗：（1）全部文檔是否完備，并已更新；）全部文檔是否完備，并已更新；（2）所有測試用例和測試結果已經(jīng)正確記載；）所有測試用例和測試結果已經(jīng)正確記載；（3）記錄軟件配

37、置所有副本的工作已經(jīng)完成；）記錄軟件配置所有副本的工作已經(jīng)完成；（4）維護工序和責任是明確的。）維護工序和責任是明確的。12.3 程序修改的步驟及修改的副作用 所謂所謂軟件可維護性軟件可維護性，是指糾正軟件系統(tǒng)出現(xiàn)的錯誤和缺陷，是指糾正軟件系統(tǒng)出現(xiàn)的錯誤和缺陷，以及為滿足新的要求進行修改、擴充或壓縮的容易度。以及為滿足新的要求進行修改、擴充或壓縮的容易度。 軟件的可維護性是軟件開發(fā)階段各個時期的關鍵目標。目軟件的可維護性是軟件開發(fā)階段各個時期的關鍵目標。目前廣泛使用的是用如下的前廣泛使用的是用如下的7個特性衡量程序的可維護性。而個特性衡量程序的可維護性。而且對于不同類型的維護，這且對于不同類型

38、的維護，這7種特性的側重點也不相同。下種特性的側重點也不相同。下表所示為在各類維護中的側重點，表中的表所示為在各類維護中的側重點，表中的“”表示需要的表示需要的特性。特性。12.4 軟件的可維護性 軟件可維護性的定義軟件可維護性的定義 軟件度量學軟件度量學是一門研究對軟件的可維護性做出定量度量是一門研究對軟件的可維護性做出定量度量的學科。度量一個可維護程序的的學科。度量一個可維護程序的7種特性常用的方法有種特性常用的方法有質量質量檢查表檢查表、質量測試質量測試和和質量標準質量標準。質量檢查表質量檢查表是用于測試程是用于測試程序中某些質量特性是否存在的一個問題清單。評價者針對序中某些質量特性是否

39、存在的一個問題清單。評價者針對檢查表上的每一個問題，依據(jù)自己的定性判斷，回答檢查表上的每一個問題，依據(jù)自己的定性判斷，回答“Yes”或者或者“No”。質量測試與質量標準質量測試與質量標準則用于定量分析則用于定量分析和和評價程序的質量。由于許多質量特性是相互抵觸的，要考評價程序的質量。由于許多質量特性是相互抵觸的，要考慮幾種不同的度量標準，相應地去度量不同的質量特性。慮幾種不同的度量標準，相應地去度量不同的質量特性。 12.4 軟件的可維護性 可維護性的度量可維護性的度量 1可理解性可理解性 可理解性可理解性表明人們通過閱讀源代碼和相關文檔，了解程序表明人們通過閱讀源代碼和相關文檔，了解程序功能

40、及其如何運行的容易程度。一個可理解的程序主要應具功能及其如何運行的容易程度。一個可理解的程序主要應具備以下一些特性：模塊化、風格一致性、不使用令人捉摸不備以下一些特性：模塊化、風格一致性、不使用令人捉摸不定或含糊不清的代碼、使用有意義的數(shù)據(jù)名和過程名、結構定或含糊不清的代碼、使用有意義的數(shù)據(jù)名和過程名、結構化、完整性等?；⑼暾缘?。 可理解性可以通過可理解性可以通過 “90-10測試測試”的方法來衡量，即把一的方法來衡量，即把一份份被測試的源程序清單拿給一位有經(jīng)驗的程序員閱讀被測試的源程序清單拿給一位有經(jīng)驗的程序員閱讀10分鐘。分鐘。若該程序員能憑自己的理解和記憶寫出該程序的若該程序員能憑自

41、己的理解和記憶寫出該程序的90%以上。以上。則認為這個程序具有可理解性，否則這個程序要重新編寫。則認為這個程序具有可理解性，否則這個程序要重新編寫。12.4 軟件的可維護性 2可靠性可靠性 可靠性表明可靠性表明一個程序按照用戶的要求和設計目標，在給定一個程序按照用戶的要求和設計目標，在給定的一段時間內(nèi)正確執(zhí)行的概率。的一段時間內(nèi)正確執(zhí)行的概率?？煽啃远攘康臉藴士煽啃远攘康臉藴手饕校褐饕校浩骄чg隔時間（平均失效間隔時間（mean time to failure，MTTF）、）、平均平均修復時間（修復時間（mean time to repair error，MTTR）、）、有效性有效性A（

42、=MTBD/（MTBD+MDT）。）。度量可靠性的方法度量可靠性的方法主要有主要有如下兩類：如下兩類：（1）根據(jù)程序錯誤統(tǒng)計數(shù)字，進行可靠性預測。）根據(jù)程序錯誤統(tǒng)計數(shù)字，進行可靠性預測。 （2）根據(jù)程序復雜性，預測軟件可靠性。）根據(jù)程序復雜性，預測軟件可靠性。12.4 軟件的可維護性 3可測試性可測試性 可測試性表明可測試性表明論證程序正確性的容易程度。程序越簡單，論證程序正確性的容易程度。程序越簡單，證明其正確性就越容易。而且設計合適的測試用例，取決于證明其正確性就越容易。而且設計合適的測試用例，取決于對程序的全面理解，因此，一個可測試的程序應當是可理解對程序的全面理解，因此，一個可測試的程

43、序應當是可理解的、可靠的、簡單的。的、可靠的、簡單的。 對于程序模塊，可用程序復雜性來度量可測試性。程序的對于程序模塊，可用程序復雜性來度量可測試性。程序的環(huán)路復雜性越大，程序的路徑就越多，因此，全面測試程序環(huán)路復雜性越大，程序的路徑就越多，因此，全面測試程序的難度就越大。的難度就越大。12.4 軟件的可維護性 4可修改性可修改性 可修改性可修改性表明程序容易修改的程度。一個可修改的程序應表明程序容易修改的程度。一個可修改的程序應當是當是可理解的可理解的、通用的通用的、靈活的靈活的、簡單的簡單的。 測試可修改性的一種定量方法是測試可修改性的一種定量方法是修改練習修改練習。其。其基本思想基本思想

44、是是通過做幾個簡單的修改，來評價修改的難度。設通過做幾個簡單的修改，來評價修改的難度。設C是程序中是程序中各個模塊的復雜性，各個模塊的復雜性，n是必須修改的模塊數(shù)，是必須修改的模塊數(shù)，A是要修改的是要修改的模塊的復雜性。則修改的難度模塊的復雜性。則修改的難度D由下式計算：由下式計算：D=A/C 對于簡單的修改，若對于簡單的修改，若D1，說明該程序修改困難。，說明該程序修改困難。A和和C可用任何一種度量程序復雜性的方法計算?？捎萌魏我环N度量程序復雜性的方法計算。12.4 軟件的可維護性 5可移植性可移植性 可移植性可移植性表明程序轉移到一個新的計算環(huán)境的可能性的表明程序轉移到一個新的計算環(huán)境的可

45、能性的大小。或者它表明程序可以容易地、有效地在各種各樣的大小?；蛘咚砻鞒绦蚩梢匀菀椎亍⒂行У卦诟鞣N各樣的計算環(huán)境中運行的容易程度。計算環(huán)境中運行的容易程度。 一個可移植的程序應具有結構良好、靈活、不依賴于某一個可移植的程序應具有結構良好、靈活、不依賴于某一具體計算機或操作系統(tǒng)的性能。一具體計算機或操作系統(tǒng)的性能。6效率效率 效率效率表明一個程序能執(zhí)行預定功能而又不浪費機器資源表明一個程序能執(zhí)行預定功能而又不浪費機器資源的程度。這些機器資源包括內(nèi)存容量、外存容量、通道容的程度。這些機器資源包括內(nèi)存容量、外存容量、通道容量和執(zhí)行時間。量和執(zhí)行時間。12.4 軟件的可維護性 7可使用性可使用性 從

46、用戶觀點出發(fā)，從用戶觀點出發(fā)，可使用性可使用性是指程序方便、實用及易于使是指程序方便、實用及易于使用的程度。一個可使用的程序應是易于使用的、能允許用戶用的程度。一個可使用的程序應是易于使用的、能允許用戶出錯和改變，并盡可能不使用戶陷入混亂狀態(tài)的程序。出錯和改變，并盡可能不使用戶陷入混亂狀態(tài)的程序。 用于可使用性度量的檢查項目主要有：用于可使用性度量的檢查項目主要有：（1）程序是否具有自描述性？）程序是否具有自描述性？（2）程序是否能始終如一地按照用戶的要求運行？）程序是否能始終如一地按照用戶的要求運行？（3）程序是否讓用戶對數(shù)據(jù)處理有一個滿意的和適當?shù)目兀┏绦蚴欠褡層脩魧?shù)據(jù)處理有一個滿意的和

47、適當?shù)目?制？制？（4）程序是否容易學會使用？）程序是否容易學會使用？12.4 軟件的可維護性 （5）程序是否使用數(shù)據(jù)管理系統(tǒng)來自動地處理事務性工作）程序是否使用數(shù)據(jù)管理系統(tǒng)來自動地處理事務性工作 和管理格式化、地址分配及存儲器組織。和管理格式化、地址分配及存儲器組織。（6）程序是否具有容錯性？）程序是否具有容錯性？（7）程序是否靈活？）程序是否靈活？8其他間接定量度量可維護性的方法其他間接定量度量可維護性的方法 Gilb提出了與軟件維護期間工作量有關的一些數(shù)據(jù)，可以提出了與軟件維護期間工作量有關的一些數(shù)據(jù)，可以使用它們間接地對軟件的可維護性做出估計。使用它們間接地對軟件的可維護性做出估計。（

48、1）問題識別的時間；）問題識別的時間；（2）因管理活動拖延的時間；）因管理活動拖延的時間；（3）收集維護工具的時間；）收集維護工具的時間；12.4 軟件的可維護性 （4）分析、診斷問題的時間；）分析、診斷問題的時間；（5）修改規(guī)格說明的時間；）修改規(guī)格說明的時間；（6）具體的改錯或修改的時間；）具體的改錯或修改的時間；（7）局部測試的時間；）局部測試的時間；（8）集成或回歸測試的時間；）集成或回歸測試的時間；（9）維護的評審時間；）維護的評審時間；（10）恢復時間。）恢復時間。 這些數(shù)據(jù)反映了維護全過程中檢錯這些數(shù)據(jù)反映了維護全過程中檢錯-糾錯糾錯-驗證的周期，即驗證的周期，即從檢測出軟件存在

49、的問題開始至修正它們并經(jīng)回歸測試驗證從檢測出軟件存在的問題開始至修正它們并經(jīng)回歸測試驗證這段時間。可以粗略地認為，這個周期越短，維護越容易。這段時間。可以粗略地認為，這個周期越短，維護越容易。 12.4 軟件的可維護性 一個可維護的程序應是可理解的、可靠的、可測試的、可一個可維護的程序應是可理解的、可靠的、可測試的、可修改的、可移植的、效率高的、可使用的。盡管可維護性要修改的、可移植的、效率高的、可使用的。盡管可維護性要求每一種質量特性都要得到滿足，但它們的相對重要性應隨求每一種質量特性都要得到滿足，但它們的相對重要性應隨程序的用途及計算環(huán)境的不同而不同。例如，對編譯程序來程序的用途及計算環(huán)境

50、的不同而不同。例如，對編譯程序來說，可能強調效率；但對管理信息系統(tǒng)來說，則可能強調可說，可能強調效率；但對管理信息系統(tǒng)來說，則可能強調可使用性和可修改性。所以，應當對程序的質量特性，在提出使用性和可修改性。所以，應當對程序的質量特性，在提出目標的同時還必須規(guī)定它們的優(yōu)先級。這樣有助于提高軟件目標的同時還必須規(guī)定它們的優(yōu)先級。這樣有助于提高軟件的質量，并對軟件生存期的費用產(chǎn)生很大的影響。的質量，并對軟件生存期的費用產(chǎn)生很大的影響。 12.5 提高可維護性的方法 建立明確的軟件質量目標和優(yōu)先級建立明確的軟件質量目標和優(yōu)先級1模塊化模塊化 模塊化技術的優(yōu)點是如果需要改變某個模塊的功能，則模塊化技術的

51、優(yōu)點是如果需要改變某個模塊的功能，則只要改變這個模塊，對其他模塊影響很小；如果需要增加只要改變這個模塊，對其他模塊影響很?。蝗绻枰黾映绦虻哪承┕δ?，則僅需增加完成這些功能的新的模塊或程序的某些功能，則僅需增加完成這些功能的新的模塊或模塊層；程序的測試與重復測試比較容易；程序錯誤易于模塊層；程序的測試與重復測試比較容易；程序錯誤易于定位和糾正；容易提高程序效率。定位和糾正；容易提高程序效率。2結構化程序設計結構化程序設計 結構化程序設計不僅使得模塊結構標準化，而且將模塊結構化程序設計不僅使得模塊結構標準化，而且將模塊間的相互作用也標準化了，因而把模塊化又向前推進了一間的相互作用也標準化了，因

52、而把模塊化又向前推進了一步。采用結構化程序設計可以獲得良好的程序結構。步。采用結構化程序設計可以獲得良好的程序結構。 使用提高軟件質量的技術和工具使用提高軟件質量的技術和工具 12.5 提高可維護性的方法3使用結構化程序設計技術，提高現(xiàn)有系統(tǒng)的可使用結構化程序設計技術，提高現(xiàn)有系統(tǒng)的可 維護性維護性 （1）采用備用件的方法）采用備用件的方法當要修改某一個模塊時，用一當要修改某一個模塊時，用一 個新的結構良好的模塊替換掉整個模塊。個新的結構良好的模塊替換掉整個模塊。 （2）采用自動重建結構和重新格式化的工具（結構更新技）采用自動重建結構和重新格式化的工具（結構更新技 術）。術）。（3）改進現(xiàn)有程

53、序的不完善的文檔。）改進現(xiàn)有程序的不完善的文檔。（4）使用結構化程序設計方法實現(xiàn)新的子系統(tǒng)。）使用結構化程序設計方法實現(xiàn)新的子系統(tǒng)。（5）采用結構化小組。）采用結構化小組。12.5 提高可維護性的方法 質量保證審查除了保證軟件得到適當?shù)馁|量外，還可以用質量保證審查除了保證軟件得到適當?shù)馁|量外，還可以用來檢測在開發(fā)和維護階段內(nèi)發(fā)生的質量變化。一旦檢測出問來檢測在開發(fā)和維護階段內(nèi)發(fā)生的質量變化。一旦檢測出問題來，就可以采取措施糾正，以控制不斷增長的軟件維護成題來，就可以采取措施糾正，以控制不斷增長的軟件維護成本。本。 為了保證軟件的可維護性，有為了保證軟件的可維護性，有4種類型的軟件審查。種類型的

54、軟件審查。 1在檢查點進行復審在檢查點進行復審 保證軟件質量的最佳方法是在軟件開發(fā)的最初階段就把質保證軟件質量的最佳方法是在軟件開發(fā)的最初階段就把質量要求考慮進去，并在開發(fā)過程每一個階段的終點，設置檢量要求考慮進去，并在開發(fā)過程每一個階段的終點，設置檢查點進行檢查。檢查的目的是要證實，已開發(fā)的軟件是否符查點進行檢查。檢查的目的是要證實，已開發(fā)的軟件是否符合標準，是否滿足規(guī)定的質量需求。合標準，是否滿足規(guī)定的質量需求。 12.5 提高可維護性的方法 質量保證審查質量保證審查 在不同的檢查點，檢查的重點不完全相同，例如，在設計階在不同的檢查點，檢查的重點不完全相同，例如，在設計階段，檢查重點是可理

55、解性、可修改性、可測試性。可理解性段，檢查重點是可理解性、可修改性、可測試性。可理解性檢查的重點是程序的復雜性。如下圖所示。檢查的重點是程序的復雜性。如下圖所示。12.5 提高可維護性的方法可以使用各種質量特性檢查表，或用度量標準來檢查可維可以使用各種質量特性檢查表，或用度量標準來檢查可維護性。各種度量標準應當在管理部門、用戶、軟件開發(fā)人護性。各種度量標準應當在管理部門、用戶、軟件開發(fā)人員、軟件維護人員當中達成一致意見。審查小組可以采用員、軟件維護人員當中達成一致意見。審查小組可以采用人工測試一類的方式進行審查。人工測試一類的方式進行審查。 2驗收檢查驗收檢查 驗收檢查是一個特殊的檢查點的檢查

56、，是交付使用前的最驗收檢查是一個特殊的檢查點的檢查，是交付使用前的最后一次檢查，是軟件投入運行之前保證可維護性的最后機后一次檢查，是軟件投入運行之前保證可維護性的最后機會。它實際上是驗收測試的一部分，只不過它是從維護的角會。它實際上是驗收測試的一部分，只不過它是從維護的角度提出驗收的條件和標準。度提出驗收的條件和標準。 以下是驗收檢查必須遵循的最小驗收標準。以下是驗收檢查必須遵循的最小驗收標準。（1）需求和規(guī)范標準）需求和規(guī)范標準 需求應當以可測試的術語進行書寫，按優(yōu)先次序排列和需求應當以可測試的術語進行書寫，按優(yōu)先次序排列和定義。定義。 區(qū)分必須的、任選的、將來的需求。區(qū)分必須的、任選的、將

57、來的需求。12.5 提高可維護性的方法 包括對系統(tǒng)運行時的計算機設備的需求；對維護、測包括對系統(tǒng)運行時的計算機設備的需求；對維護、測 試、操作，以及維護人員的需求；對測試工具等的需求。試、操作，以及維護人員的需求；對測試工具等的需求。（2）設計標準）設計標準 程序應設計成分層的模塊結構。每個模塊應完成唯一的程序應設計成分層的模塊結構。每個模塊應完成唯一的 功能，并達到高內(nèi)聚、低耦合。功能，并達到高內(nèi)聚、低耦合。 通過一些知道預期變化的實例，說明設計的可擴充性、通過一些知道預期變化的實例，說明設計的可擴充性、 可縮減性和可適應性?？煽s減性和可適應性。（3）源代碼標準）源代碼標準 盡可能使用程序設

58、計語言的標準版本。盡可能使用程序設計語言的標準版本。 所有的代碼都必須具有良好的結構。所有的代碼都必須具有良好的結構。12.5 提高可維護性的方法 所有的代碼都必須文檔化，在注釋中說明它的輸入、輸出，所有的代碼都必須文檔化，在注釋中說明它的輸入、輸出，以及便于測試以及便于測試/再測試的一些特點與風格。再測試的一些特點與風格。（4）文檔標準）文檔標準 文檔中應說明程序的輸入文檔中應說明程序的輸入/輸出、使用的方法輸出、使用的方法/算法、錯誤恢算法、錯誤恢復方法、所有參數(shù)的范圍、默認條件等。復方法、所有參數(shù)的范圍、默認條件等。3周期性地維護審查周期性地維護審查 檢查點復查和驗收檢查，可用來保證新軟件系統(tǒng)的可維護性。檢查點復查和驗收檢查，可用來保證新軟件系統(tǒng)的可維護性。對已有的軟件系統(tǒng)，則應當進行周期性的維護檢查。對已有的軟件系統(tǒng)，則應當進行周期性的維護檢查