軟件工程第八章維護軟件生存周期第8章維護軟件維護是軟件生命周期的最后一個階段，它處于系統(tǒng)投入生產(chǎn)性運行以后的時期中，因此不屬于系統(tǒng)開發(fā)過程。軟件維護的基本任務是保證軟件在一個相當長的時期能夠正常運行。軟件維護需要的工作量非常大，雖然在不同應用領(lǐng)域維護成本差別很大，但是，平均說來，大型軟件的維護成本高達開發(fā)成本的四倍左右。軟件維護定義所謂軟件維護就是在軟件已經(jīng)交付使用之后，為了改正錯誤或滿足新的需要而修改軟件的過程。軟件維護包括下述4項活動。診斷和改正錯誤的過程：改正性維護為了和變化了的環(huán)境適當?shù)嘏浜隙M行的修改軟件的活動：適應性維護為了滿足在使用軟件的過程中用戶的建議和改進意見而作的維護：完善性維護為了給未來的改進奠定更好的基礎(chǔ)而修改軟件：預防性維護在軟件交付使用后，因開發(fā)時測試的不徹底、不完全，必然會有部分隱藏的錯誤遺留到運行階段。這些隱藏下來的錯誤在某些特定的使用環(huán)境下就會暴露出來。為了識別和糾正軟件錯誤、改正軟件性能上的缺陷、排除實施中的誤使用，應當進行的診斷和改正錯誤的過程就叫做改正性維護。改正性維護的工作量占全部維護活動的17%～21%。1、改正（糾錯）性維護適應性維護，也就是為了和變化了的環(huán)境適當?shù)嘏浜隙M行的修改軟件的活動，是既必要又經(jīng)常的維護活動。外部環(huán)境（新的硬、軟件配置）數(shù)據(jù)環(huán)境（數(shù)據(jù)庫、數(shù)據(jù)格式、數(shù)據(jù)輸入/輸出方式、數(shù)據(jù)存儲介質(zhì)）可能發(fā)生變化。適應性維護的工作量占全部維護活動的18%～25%2、適應性維護在軟件的使用過程中，用戶往往會對軟件提出新的功能與性能要求。為了滿足這些要求，需要修改或再開發(fā)軟件，以擴充軟件功能、增強軟件性能、改進加工效率、提高軟件的可維護性。這種情況下進行的維護活動叫做完善性維護。3、完善性維護實踐表明，在幾種維護活動中，完善性維護所占的比重最大。即大部分維護工作是改變和加強軟件，而不是糾錯。完善性維護不一定是救火式的緊急維修，而可以是有計劃、有預謀的一種再開發(fā)活動。事實證明，來自用戶要求擴充、加強軟件功能、性能的維護活動約占整個維護工作的50％以上。3、完善性性維護預防性維護是為了提高軟件的可維護性、可靠性等，為以后進一步改進軟件打下良好基礎(chǔ)。預防性維護定義為：采用先進的軟件工程方法對需要維護的軟件或軟件中的某一部分（重新）進行設(shè)計、編制和測試。在整個維護活動中，預防性維護占很小的比例，只占5%。4、預防性維護綜述在整個軟件維護階段所花費的全部工作量中，完善性維護占了幾乎一半的工作量。軟件維護活動所花費的工作占整個生存期工作量的70%以上，這是由于在漫長的軟件運行過程中需要不斷對軟件進行修改，以改正新發(fā)現(xiàn)的錯誤、適應新的環(huán)境和用戶新的要求，這些修改需要花費很多精力和時間，而且有時會引入新的錯誤。軟件維護定義三類維護占維護在軟件生

總維護比例存期所占比例

8.2維護的特點結(jié)構(gòu)化維護與非結(jié)構(gòu)化維護的差別巨大1.非結(jié)構(gòu)化維護 如果軟件配置的唯一成分是程序代碼，那么維護活動從艱苦地評價程序代碼開始，而且常常由于程序內(nèi)部文檔不足而使評價更困難。而且對程序代碼所做的改動的后果是難于估量的：因為沒有測試方面的文檔，所以不可能進行回歸測試。非結(jié)構(gòu)化維護付出代價高昂。8.2維護的特點2.結(jié)構(gòu)化維護 如果有一個完整的軟件配置存在，那么維護工作從評價設(shè)計文檔開始，確定軟件重要的結(jié)構(gòu)特點、性能特點以及接口特點；估量要求的改動將帶來的影響，并且計劃實施途徑。然后首先修改設(shè)計并且對所做的修改進行仔細復查。接下來編寫相應的源程序代碼；使用在測試說明書中包含的信息進行回歸測試；最后，把修改后的軟件再次交付使用。結(jié)構(gòu)化維護能減少精力浪費并且能提高維護的總體質(zhì)量。8.2維護的特點二、維護成本有形的軟件維護成本是花費了多少錢，無形的維護成本有更大的影響。一些合理的修復或修改請求不能及時安排，使得客戶不滿意；變更的結(jié)果引入新的故障，使得軟件整體質(zhì)量下降；把軟件人員抽調(diào)到維護工作中，干擾了軟件開發(fā)工作。軟件維護的代價是降低了生產(chǎn)率，在做老程序的維護時非常明顯。例如，開發(fā)每一行源代碼耗資25美元，維護每一行源代碼需要耗資1000美元。8.2維護的特點維護工作量的一個模型：

M＝P＋K*exp（c-d）其中：

M是維護用的總工作量，

P是生產(chǎn)性工作量，

K是經(jīng)驗常數(shù)，

c是因缺乏好的設(shè)計和文檔而導致復雜性的度量），

d是維護人員對軟件的熟悉程度。模型表明，如果軟件的開發(fā)途徑不好(即，沒有使用軟件工程方法學)，而且原來的開發(fā)人員不能參加維護工作，那么維護工作量和費用將指數(shù)地增加。影響維護工作量的因素在軟件的維護過程中，需要花費大量的工作量，從而直接影響了軟件維護的成本。許多軟件在開發(fā)時并未考慮將來的修改，為軟件的維護帶來許多問題。系統(tǒng)大?。合到y(tǒng)越大，理解掌握起來越困難。系統(tǒng)越大，所執(zhí)行功能越復雜。因而需要更多的維護工作量。程序設(shè)計語言：使用強功能的程序設(shè)計語言可以控制程序的規(guī)模。語言的功能越強，生成程序的模塊化和結(jié)構(gòu)化程度越高，所需的指令數(shù)就越少，程序的可讀性越好。

系統(tǒng)年齡：老系統(tǒng)隨著不斷的修改，結(jié)構(gòu)越來越亂；維護人員經(jīng)常更換，程序又變得越來越難于理解。許多老系統(tǒng)在當初并未按照軟件工程的要求進行開發(fā)，因而沒有文檔，或文檔太少。在長期的維護過程中文檔在許多地方與程序?qū)崿F(xiàn)變得不一致，在維護時就會遇到很大困難。許多軟件的維護十分困難，原因在于這些軟件的文檔不全、質(zhì)量差、開發(fā)過程不注意采用好的方法，忽視程序設(shè)計風格等。容易導致設(shè)計與數(shù)據(jù)不相容的錯誤可以有：程序在執(zhí)行之前是否測定當前的輸入／輸出設(shè)備?(2)修改數(shù)據(jù)的副作用由于數(shù)據(jù)體系結(jié)構(gòu)對程序體系結(jié)構(gòu)及程序中的算法有很大影響，對數(shù)據(jù)的修改必然會導致體系結(jié)構(gòu)或代碼層的改變。（4）使用的程序設(shè)計語言；如果僅有程序代碼沒有說明文檔，則會出現(xiàn)嚴重的問題。程序中是否避免了依賴于字母數(shù)字或特殊字符的內(nèi)部位表示?接下來編寫相應的源程序代碼；是否盡可能地使用了整數(shù)運算，而不是實數(shù)運算?程序越簡單，證明其正確性就越容易。在幾條分支結(jié)構(gòu)中，是否最有可能為“真”的分支首先得到測試?模型表明，如果軟件的開發(fā)途徑不好(即，沒有使用軟件工程方法學)，而且原來的開發(fā)人員不能參加維護工作，那么維護工作量和費用將指數(shù)地增加。（1）每次程序運行平均失效的次數(shù)；系統(tǒng)越大，所執(zhí)行功能越復雜。數(shù)據(jù)庫技術(shù)的應用：使用數(shù)據(jù)庫，可以簡單而有效地管理和存儲用戶程序中的數(shù)據(jù)，還可以減少生成用戶報表應用軟件的維護工作量。先進的軟件開發(fā)技術(shù)：在軟件開發(fā)時，若使用能使軟件結(jié)構(gòu)比較穩(wěn)定的分析與設(shè)計技術(shù)，及程序設(shè)計技術(shù)，如面向?qū)ο蠹夹g(shù)、復用技術(shù)等，可減少大量的工作量。8.2維護的特點維護的問題與軟件維護有關(guān)的絕大多數(shù)問題，都可歸因于軟件定義和軟件開發(fā)的方法有缺點。在軟件生命周期的頭兩個時期沒有嚴格而又科學的管理和規(guī)劃，幾乎必然會導致在最后階段出現(xiàn)問題。8.2維護的特點和軟件維護有關(guān)的部分問題：理解別人寫的程序通常非常困難，而且困難程度隨著軟件配置成分的減少而迅速增加。如果僅有程序代碼沒有說明文檔，則會出現(xiàn)嚴重的問題。需要維護的軟件往往沒有合格的文檔，或者文檔資料顯著不足。認識到軟件必須有文檔僅僅是第一步，容易理解的并且和程序代碼完全一致的文檔才真正有價值。當要求對軟件進行維護時，不能指望由開發(fā)人員給我們仔細說明軟件。由于維護“階段持續(xù)的時間很長，因此，當需要解釋軟件時，往往原來寫程序的人已經(jīng)不在附近了。8.2維護的特點絕大多數(shù)軟件在設(shè)計時沒有考慮將來的修改。除非使用強調(diào)模塊獨立原理的設(shè)計方法論，否則修改軟件既困難又容易發(fā)生差錯。軟件維護不是一項吸引人的工作。形成這種觀念很大程度上是因為維護工作經(jīng)常遭受挫折。8.3軟件維護過程維護過程本質(zhì)上是修改和壓縮了的軟件定義和開發(fā)過程。為了有效地進行軟件維護，應事先就開始做組織工作。首先建立一個維護組織確定報告及評價的過程為每一個維護要求規(guī)定一個標準化的事件序列建立一個適用于維護活動的記錄保管過程，并且規(guī)定復審標準8.3軟件維護過程維護組織維護組織

維護申請?zhí)峤唤o維護管理員，他把申請交給某個系統(tǒng)監(jiān)督員去評價。一旦做出評價，由修改負責人確定如何進行修改。在修改程序的過程中，由配置管理員嚴格把關(guān)，控制修改的范圍，對軟件配置進行審計。在維護之前，就把責任明確下來，可以減少維護過程中的混亂。

維護修改建議

分析修改建議是否合理提交管理部門審查是否同意修改撤銷NYNY進行測試

提交管理部門審批是否批準更新主文檔Y

更新其他文檔

提交使用修改N軟件維護的管理流程8.3軟件維護過程維護報告應該用標準化的格式表達所有軟件維護要求。軟件維護人員給用戶提供空白的維護要求——有時稱為軟件問題報告表，由要求一項維護活動的用戶填寫。如果遇到了一個錯誤，那么必須完整描述導致出現(xiàn)錯誤的環(huán)境（包括輸入數(shù)據(jù)，全部輸出數(shù)據(jù)，以及其他有關(guān)信息）。對于適應性或完善性的維護要求，應該提出一個簡短的需求說明書。由維護管理員和系統(tǒng)管理員評價用戶提交的維護要求表。8.3軟件維護過程維護的事件流8.3軟件維護過程保存維護記錄應該為每項維護工作都收集下述數(shù)據(jù)：（1）程序標識；（2）源語句數(shù)；（3）機器指令條數(shù)；（4）使用的程序設(shè)計語言；（5）程序安裝的日期；（6）自從安裝以來程序運行的次數(shù)；（7）自從安裝以來程序失效的次數(shù)；（8）程序變動的層次和標識；（9）因程序變動而增加的源語句數(shù)；（10）因程序變動而刪除的源語句數(shù)；（11）每個改動耗費的人時數(shù)；（12）程序改動的日期；（13）軟件工程師的名字；（14）維護要求表的標識；（15）維護類型；（l6）維護開始和完成的日期；（17）累計用于維護的人時數(shù)；（18）與完成的維護相聯(lián)系的純效益。8.3軟件維護過程評價維護活動從下述七個方面度量維護工作：（1）每次程序運行平均失效的次數(shù)；（2）用于每一類維護活動的總?cè)藭r數(shù)；（3）平均每個程序、每種語言、每種維護類型所做的程序變動效；（4）維護過程中增加或刪除一個源語句平均花費的人時數(shù)；（5）維護每種語言平均花費的人時數(shù)；（6）一張維護要求表的平均周轉(zhuǎn)時間；（7）不同維護類型所占的百分比。計算機確認

在進行了以上確認的基礎(chǔ)上，用計算機對修改程序進行確認測試：

(1)確認測試順序：先對修改部分進行測試，然后隔離修改部分，測試程序的未修改部分，最后再把它們集成起來進行測試。程序是否讓用戶對數(shù)據(jù)處理有一個滿意的和適當?shù)目刂?所謂副作用是指因修改軟件而造成的錯誤或其它不希望發(fā)生的情況。在復雜的邏輯條件中，是否最有可能為“真“的表達式首先得到測試?每個軟件組織都應該保存其擁有的所有應用系統(tǒng)的庫存目錄。(4)不要試圖共用程序中已有的臨時變量或工作區(qū)，為了避免沖突或混淆用途，應設(shè)置自己的變量；而且對于不同類型的維護，這七種特性的側(cè)重點也不相同。在長期的維護過程中文檔在許多地方與程序?qū)崿F(xiàn)變得不一致，在維護時就會遇到很大困難。維護人員理解、改正、改動和改進這個軟件的難易程度。使用提高軟件質(zhì)量的技術(shù)和工具而且對于不同類型的維護，這七種特性的側(cè)重點也不相同。在修改程序的過程中，由配置管理員嚴格把關(guān)，控制修改的范圍，對軟件配置進行審計。為了滿足在使用軟件的過程中用戶的建議和改進意見而作的維護：完善性維護一個可移植的程序應具有結(jié)構(gòu)良好、靈活、不依賴于某一具體計算機或操作系統(tǒng)的性能。對庫中每個程序都做逆向工程或再工程是不現(xiàn)實的。8.4程序修改的步驟及修改的副作用在軟件維護時，必然會對源程序進行修改。通常對源程序的修改不能無計劃地倉促上陣，為了正確、有效地修改,需要經(jīng)歷以下三個步驟。

分析和理解程序

修改程序

重新驗證程序分析和理解程序經(jīng)過分析，全面、準確、迅速地理解程序是決定維護成敗和質(zhì)量好壞的關(guān)鍵。在這方面，軟件的可理解性和文檔的質(zhì)量非常重要。修改程序?qū)Τ绦虻男薷?，必須事先做出計劃，有預謀地、周密有效地實施修改。1.設(shè)計程序的修改計劃 程序的修改計劃要考慮人員和資源的安排。小的修改可以不需要詳細的計劃，而對于需要耗時數(shù)月的修改，就需要計劃立案。2.修改代碼，以適應變化

在修改時，要求：

(1)正確、有效地編寫修改代碼；

(2)要謹慎地修改程序，盡量保持程序的風格及格式，要在程序清單上注明改動的指令；

(3)不要刪除程序語句，除非完全肯定它是無用的；

(4)不要試圖共用程序中已有的臨時變量或工作區(qū)，為了避免沖突或混淆用途，應設(shè)置自己的變量；

(5)插入錯誤檢測語句；

(6)在修改過程中做好修改的詳細記錄，消除變更中任何有害的副作用（波動效應）；3.修改程序的副作用

所謂副作用是指因修改軟件而造成的錯誤或其它不希望發(fā)生的情況。副作用有三種：修改代碼的副作用、修改數(shù)據(jù)的副作用、文檔的副作用。

在修改源代碼時，都可能引入錯誤。例如，刪除或修改一個子程序、刪除或修改一個標號、刪除或修改一個標識符、改變程序代碼的時序關(guān)系、改變占用存儲的大小、改變邏輯運算符、修改文件的打開或關(guān)閉、改進程序的執(zhí)行效率，以及把設(shè)計上的改變翻譯成代碼的改變時，都容易引入錯誤。(1)修改代碼的副作用(2)修改數(shù)據(jù)的副作用在修改數(shù)據(jù)結(jié)構(gòu)時，有可能造成軟件設(shè)計與數(shù)據(jù)結(jié)構(gòu)不匹配，因而導致軟件出錯。數(shù)據(jù)副作用就是修改軟件信息結(jié)構(gòu)導致的結(jié)果。容易導致設(shè)計與數(shù)據(jù)不相容的錯誤可以有：重新定義局部的或全局的常量重新定義記錄或文件的格式增大或減小一個數(shù)組或高層數(shù)據(jù)結(jié)構(gòu)的大小修改全局或公共數(shù)據(jù)重新初始化控制標志或指針重新排列輸入／輸出或子程序的參數(shù)(3)文檔的副作用對數(shù)據(jù)流、軟件結(jié)構(gòu)、模塊邏輯或任何其它有關(guān)特性進行修改時，必須對相關(guān)技術(shù)文檔進行相應修改。否則會導致文檔與程序功能不匹配，缺省條件改變，新錯誤信息不正確等錯誤。使得軟件文檔不能反映軟件的當前狀態(tài)。對于用戶來說，軟件事實上就是文檔。如果對可執(zhí)行軟件的修改不反映在文檔里，就會產(chǎn)生文檔的副作用。對交互輸入的順序或格式進行修改，如果沒有正確地記入文檔中，就可能引起重大的問題。過時的文檔內(nèi)容、索引和文本可能造成沖突，引起用戶失敗和不滿。因此，必須在軟件交付之前對整個軟件配置進行評審，以減少文檔的副作用。重新驗證程序在將修改后的程序提交用戶之前，需要進行充分的確認和測試，以保證整個修改后程序的正確性。靜態(tài)確認

修改軟件，伴隨著引起新的錯誤的危險。為了能夠做出正確的判斷，驗證修改后的程序至少需要兩個人參加。要檢查：

(1)修改是否涉及到規(guī)格說明?修改結(jié)果是否符合規(guī)格說明?有沒有歪曲規(guī)格說明?

(2)程序的修改是否足以修正軟件中的問題?源程序代碼有無邏輯錯誤?修改時有無修補失誤?

(3)修改部分對其它部分有無不良影響(副作用)?

對軟件進行修改，常常會引發(fā)別的問題，有必要檢查修改的影響范圍。計算機確認

在進行了以上確認的基礎(chǔ)上，用計算機對修改程序進行確認測試：

(1)確認測試順序：先對修改部分進行測試，然后隔離修改部分，測試程序的未修改部分，最后再把它們集成起來進行測試。這種測試稱為回歸測試。

(2)準備標準的測試用例。

(3)充分利用軟件工具幫助重新驗證過程。

(4)在重新確認過程中，需邀請用戶參加。維護后的驗收──在交付新軟件之前，維護主管部門要檢驗：

(1)全部文檔是否完備，并已更新；

(2)所有測試用例和測試結(jié)果已經(jīng)正確記載；

(3)記錄軟件配置所有副本的工作已經(jīng)完成；

(4)維護工序和責任已經(jīng)確定。8.5軟件的可維護性許多軟件的維護十分困難，原因在于這些軟件的文檔不全、質(zhì)量差、開發(fā)過程不注意采用好的方法，忽視程序設(shè)計風格等。許多維護要求并不是因為程序中出錯而提出的，而是為適應環(huán)境變化或需求變化而提出的。為了使得軟件能夠易于維護，必須考慮使軟件具有可維護性。8.5軟件的可維護性軟件可維護性可以定性地定義為：維護人員理解、改正、改動和改進這個軟件的難易程度。軟件的可維護性是軟件開發(fā)階段各個時期的關(guān)鍵目標。軟件可維護性的因素目前廣泛使用的是用如下的七個特性來衡量程序的可維護性。 可理解性 可使用性 可測試性 可移植性 可修改性 效率 可靠性而且對于不同類型的維護，這七種特性的側(cè)重點也不相同。軟件可維護性的因素軟件可維護性的度量人們一直期望對軟件的可維護性做出定量度量，但要做到這一點并不容易。常用的度量一個可維護的程序的七種特性的方法。1.可理解性可理解性表明人們通過閱讀源代碼和相關(guān)文檔，了解程序功能及其如何運行的容易程度。一個可理解的程序應具備以下一些特性：模塊化，風格一致性，不使用令人捉摸不定或含糊不清的代碼，使用有意義的數(shù)據(jù)名和過程名，結(jié)構(gòu)化，完整性等。2.可靠性可靠性表明一個程序按照用戶的要求和設(shè)計目標，在給定的一段時間內(nèi)正確執(zhí)行的概率。關(guān)于可靠性，度量的標準主要有： 平均失效間隔時間MTTF

平均修復時間MTTR

有效性A=MTBD/(MTBD+MDT)注：系統(tǒng)平均不工作間隔時間MTBD(MeanTimeBetweenSystemDowns)、平均停機時間MDT(MeanDownTime)3.可測試性可測試性表明論證程序正確性的容易程度。程序越簡單，證明其正確性就越容易。而且設(shè)計合用的測試用例，取決于對程序的全面理解。一個可測試的程序應當是可理解的，可靠的，簡單的。用于可測試性度量的檢查項目如下：程序是否模塊化?結(jié)構(gòu)是否良好?程序是否可理解?程序是否可靠?程序是否能顯示任意中間結(jié)果?程序是否能以清楚的方式描述它的輸出?程序是否能及時地按照要求顯示所有的輸入?程序是否有跟蹤及顯示邏輯控制流程的能力?程序是否能從檢查點再啟動?程序是否能顯示帶說明的錯誤信息?4.可修改性可修改性表明程序容易修改的程度。一個可修改的程序應當是可理解的、通用的、靈活的、簡單的。通用性是指程序適用于各種功能變化而無需修改。靈活性是指能夠容易地對程序進行修改。

5.可移植性可移植性表明程序轉(zhuǎn)移到一個新的計算環(huán)境的可能性的大小?；蛘咚砻鞒绦蚩梢匀菀椎?、有效地在各種各樣的計算環(huán)境中運行的容易程度。一個可移植的程序應具有結(jié)構(gòu)良好、靈活、不依賴于某一具體計算機或操作系統(tǒng)的性能。用于可移植性度量的檢查項目如下：

是否是用高級的獨立于機器的語言來編寫程序?是否使用廣泛使用的標準化的程序設(shè)計語言來編寫程序?是否僅使用了這種語言的標準版本和特性?程序中是否使用了標準的普遍使用的庫功能和子程序?程序中是否極少使用或根本不使用操作系統(tǒng)的功能?程序在執(zhí)行之前是否初始化內(nèi)存?程序在執(zhí)行之前是否測定當前的輸入／輸出設(shè)備?程序是否把與機器相關(guān)的語句分離了出來，集中放在了一些單獨的程序模塊中，并有說明文件?

程序是否結(jié)構(gòu)化?并允許在小一些的計算機上分段(覆蓋)運行?程序中是否避免了依賴于字母數(shù)字或特殊字符的內(nèi)部位表示?6.效率效率表明一個程序能執(zhí)行預定功能而又不浪費機器資源的程度。這些機器資源包括內(nèi)存容量、外存容量、通道容量和執(zhí)行時間。用于效率度量的檢查項目如下：程序是否模塊化?結(jié)構(gòu)是否良好?是否消除了無用的標號與表達式，以充分發(fā)揮編譯器優(yōu)化作用?在幾條分支結(jié)構(gòu)中，是否最有可能為“真”的分支首先得到測試?系統(tǒng)越大，所執(zhí)行功能越復雜。程序是否讓用戶對數(shù)據(jù)處理有一個滿意的和適當?shù)目刂?這種情況下進行的維護活動叫做完善性維護。修改代碼，以適應變化

在修改時，要求：

(1)正確、有效地編寫修改代碼；一些合理的修復或修改請求不能及時安排，使得客戶不滿意；在軟件的使用過程中，用戶往往會對軟件提出新的功能與性能要求。在軟件交付使用后，因開發(fā)時測試的不徹底、不完全，必然會有部分隱藏的錯誤遺留到運行階段。重構(gòu)難于理解、測試和維護的模塊的代碼。適應性維護的工作量占全部維護活動的18%～25%在修改程序的過程中，由配置管理員嚴格把關(guān)，控制修改的范圍，對軟件配置進行審計。和軟件維護有關(guān)的部分問題：可修改性表明程序容易修改的程度。最后，把修改后的軟件再次交付使用。（1）每次程序運行平均失效的次數(shù)；程序的編譯器是否有優(yōu)化功能?是否把特殊子程序和錯誤處理子程序都歸入了單獨的模塊中?是否以快速的數(shù)學運算代替了較慢的數(shù)學運算?是否盡可能地使用了整數(shù)運算，而不是實數(shù)運算?是否在表達式中避免了混合數(shù)據(jù)類型的使用，消除了不必要的類型轉(zhuǎn)換?程序是否避免了非標準的函數(shù)或子程序的調(diào)用?在幾條分支結(jié)構(gòu)中，是否最有可能為“真”的分支首先得到測試?在復雜的邏輯條件中，是否最有可能為“真“的表達式首先得到測試?7.可使用性從用戶觀點出發(fā)，可使用性定義為程序方便、實用、及易于使用的程度。一個可使用的程序應是易于使用的、能允許用戶出錯和改變，并盡可能不使用戶陷入混亂狀態(tài)的程序。用于可使用性度量的檢查項目如下：程序是否具有自描述性?程序是否能始終如一地按照用戶的要求運行?程序是否讓用戶對數(shù)據(jù)處理有一個滿意的和適當?shù)目刂?程序是否容易學會使用?程序是否使用數(shù)據(jù)管理系統(tǒng)來自動地處理事務性工作和管理格式化、地址分配及存儲器組織。程序是否具有容錯性?程序是否靈活?提高軟件可維護性的方法建立明確的軟件質(zhì)量目標和優(yōu)先級使用提高軟件質(zhì)量的技術(shù)和工具進行明確的質(zhì)量保證審查選擇可維護的程序設(shè)計語言改進程序的文檔8.5軟件再工程過程圖8.3軟件再工程過程模型