【正文】 ? (4) 從維護申請的類型來看是否應(yīng)當(dāng)有預(yù)防性維護 ? 情況評審對將來的維護工作如何進行會產(chǎn)生重要的影響。 評價維護 活動 ? 評價維護活動比較困難 ，因為缺乏可靠的數(shù)據(jù)。 – 每次程序運行時的平均出錯次數(shù)； – 花費在每類維護上的總“人時”數(shù)； – 每個程序、每種語言、每種維護類型的程序平均修改次數(shù)； – 因為維護，增加或刪除每個源程序語句所花費的平均“人時”數(shù)； – 用于每種語言的平均“人時”數(shù)； – 維護申請報告的平均處理時間； – 各類維護申請的百分比。 ? 在軟件維護時，必然會對源程序進行修改。 ? 分析和理解程序 ? 修改程序 ? 重新驗證程序 分析和理解程序 ? 經(jīng)過分析， 全面、準確、迅速地理解程序是決定維護成敗和質(zhì)量好壞的關(guān)鍵 。 – 理解程序的功能和目標； – 掌握程序的結(jié)構(gòu)信息，即從程序中細分出若干結(jié)構(gòu)成分。若過程 i 調(diào)用過程 j，則 D[i][j]＝ 1，否則 D[i][j]＝ 0。 (4) 分析各個過程的接口 ， 估計更改的復(fù)雜性 。 可獲得有關(guān)數(shù)據(jù)在過程間如何傳遞 ， 在過程內(nèi)如何處理 等信息。在跟蹤的過程中可在源程序中間插入自己的注釋。 4. 充分閱讀和使用源程序清單和文檔，分析現(xiàn)有文檔的合理性。 6. 如有可能，積極參加開發(fā)工作。 1. 設(shè)計程序的修改計劃 程序的修改計劃要考慮人員和資源的安排。 在編寫有關(guān)問題解決的方案時，必須充分描述修改作業(yè)的規(guī)格說明。 通常，可采用自頂向下的方法，在理解程序的基礎(chǔ)上， (1) 研究程序的各個模塊、模塊的接口、及數(shù)據(jù)庫 ，從全局的觀點，提出修改計劃。為此，要 ? 識別受修改影響的數(shù)據(jù)； ? 識別使用這些數(shù)據(jù)的程序模塊； ? 對于上面程序模塊，按是產(chǎn)生數(shù)據(jù)、修改數(shù)據(jù)、還是刪除數(shù)據(jù)進行分類； ? 識別對這些數(shù)據(jù)元素的外部控制信息； ? 識別編輯和檢查這些數(shù)據(jù)元素的地方； ? 隔離要修改的部分； (3) 詳細地分析 要修改的 、以及 那些受變更影響的模塊和數(shù)據(jù)結(jié)構(gòu) 的內(nèi)部細節(jié)， 設(shè)計修改計劃 ，標明新邏輯及要改動的現(xiàn)有邏輯。用戶的某些業(yè)務(wù)因軟件中發(fā)生問題而中斷，為不讓系統(tǒng)長時間停止運行，需把問題局部化， 在可能的范圍內(nèi)繼續(xù)開展業(yè)務(wù) 。 2. 修改代碼，以適應(yīng)變化 在修改時，要求： (1) 正確、有效地編寫修改代碼； (2) 要謹慎地修改程序，盡量保持程序的風(fēng)格及格式，要在程序清單上注明改動的指令； (3) 不要刪除程序語句，除非完全肯定它是無用的； (4) 不要試圖共用程序中已有的臨時變量或工作區(qū)，為了避免沖突或混淆用途，應(yīng)設(shè)置自己的變量； (5) 插入錯誤檢測語句； (6) 在修改過程中做好修改的詳細記錄，消除變更中任何有害的副作用（波動效應(yīng)）； 3. 修改程序的副作用 所謂副作用是指因修改軟件而造成的錯誤或其它不希望發(fā)生的情況。 ? 在修改源代碼時，都可能引入錯誤。 (1) 修改代碼的副作用 (2) 修改數(shù)據(jù)的副作用 ? 在 修改數(shù)據(jù)結(jié)構(gòu) 時，有可能造成 軟件設(shè)計與數(shù)據(jù)結(jié)構(gòu)不匹配 ，因而導(dǎo)致軟件出錯。 ? 容易導(dǎo)致設(shè)計與數(shù)據(jù)不相容的錯誤可以有： – 重新定義局部的或全局的常量 – 重新定義記錄或文件的格式 – 增大或減小一個數(shù)組或高層數(shù)據(jù)結(jié)構(gòu)的大小 – 修改全局或公共數(shù)據(jù) – 重新初始化控制標志或指針 – 重新排列輸入／輸出或子程序的參數(shù) ? 數(shù)據(jù)副作用可以通過 交叉引用表 加以控制。 (3) 文檔的副作用 ? 對 數(shù)據(jù)流 、 軟件結(jié)構(gòu) 、 模塊邏輯 或任何其它有關(guān)特性 進行修改時，必須 對相關(guān)技術(shù)文檔進行相應(yīng)修改 。使得 軟件文檔不能反映軟件的當(dāng)前狀態(tài) 。 ? 如果對可執(zhí)行軟件的修改不反映在文檔里，就會產(chǎn)生文檔的副作用。 – 過時的文檔內(nèi)容、索引和文本可能造成沖突，引起用戶失敗和不滿。 ? 為了控制因修改而引起的副作用，要做到： (1) 按模塊把修改分組； (2) 自頂向下地安排被修改模塊的順序； (3) 每次修改一個模塊； (4) 對于每個修改了的模塊，在安排修改下一個模塊之前，要確定這個修改的副作用。 重新驗證程序 ? 在將修改后的程序提交用戶之前，需要進行 充分的確認和測試 ，以保證整個修改后程序的正確性。為了能夠做出正確的判斷，驗證修改后的程序至少需要兩個人參加。 ? 計算機確認 在進行了以上確認的基礎(chǔ)上，用計算機對修改程序進行確認測試： (1) 確認測試順序：先對修改部分進行測試，然后隔離修改部分，測試程序的未修改部分，最后再把它們集成起來進行測試。 (2) 準備標準的測試用例。 (4) 在重新確認過程中，需邀請用戶參加 。 從維護角度來看所需測試種類 (1) 對 修改事務(wù) 的測試； (2) 對 修改程序 的測試； (3) 操作過程 的測試； (4) 應(yīng)用系統(tǒng)運用過程 的測試； (5) 系統(tǒng)各部分之間接口 的測試； (6) 作業(yè)控制語言 的測試； (7) 與系統(tǒng)軟件接口 的測試； (8) 軟件系統(tǒng)之間接口 的測試； (9) 安全性 測試； (10) 后備／恢復(fù)過程 的測試。 ? 許多維護要求并不是因為程序中出錯而提出的，而是為 適應(yīng)環(huán)境變化或 需求變化 而提出的。 軟件可維護性的定義 ? 軟件可維護性 是指 糾正軟件系統(tǒng)出現(xiàn)的錯誤和缺陷，以及為滿足新的要求進行修改、擴充或壓縮的容易程度 。 ? 軟件的 可維護性 是 軟件開發(fā)階段各個時期的關(guān)鍵目標 。 可理解性 可使用性 可測試性 可移植性 可修改性 效率 可靠性 ? 而且對于不同類型的維護，這七種特性的側(cè)重點也不相同 。 ? 為使每一個質(zhì)量特性都達到預(yù)定的要求，需要在軟件開發(fā)的各個階段采取相應(yīng)的措施加以保證。因此，軟件的可維護性是產(chǎn)品投入運行以前各階段面向上述各質(zhì)量特性要求進行開發(fā)的最終結(jié)果。 ? 常用的度量一個可維護的程序的七種特性的方法。 ? 評價者針對檢查表上的每一個問題，依據(jù)自己的定性判斷，回答“ Yes”或者“ No”。 ? 由于許多質(zhì)量特性是相互抵觸的，要 考慮幾種不同的度量標準 ，相應(yīng)地去度量不同的質(zhì)量特性。 ? 一個可理解的程序應(yīng)具備以下一些特性： 模塊化 ， 風(fēng)格一致性 ， 不使用令人捉摸不定或含糊不清的代碼 ，使用有意義的數(shù)據(jù)名和過程名 ， 結(jié)構(gòu)化 ， 完整性 等。 ? 關(guān)于可靠性，度量的標準主要有： – 平均失效間隔時間 MTTF – 平均修復(fù)時間 MTTR – 有效性 A = MTBD/(MTBD+MDT) 度量可靠性的方法 – 根據(jù)程序錯誤統(tǒng)計數(shù)字，進行可靠性預(yù)測 。 – 根據(jù)程序復(fù)雜性，預(yù)測軟件可靠性 。因此可用復(fù)雜性預(yù)測出錯率。 3. 可測試性 ? 可測試性表明論證程序正確性的容易程度 。而且設(shè)計合用的測試用例，取決于對程序的全面理解。 ? 用于可測試性度量的檢查項目如下： – 程序是否模塊化 ? 結(jié)構(gòu)是否良好 ? – 程序是否可理解 ? 程序是否可靠 ? – 程序是否能顯示任意中間結(jié)果 ? – 程序是否能以清楚的方式描述它的輸出 ? – 程序是否能及時地按照要求顯示所有的輸入 ? – 程序是否有跟蹤及顯示邏輯控制流程的能力 ? – 程序是否能從檢查點再啟動 ? – 程序是否能顯示帶說明的錯誤信息 ? 4. 可修改性 ? 可修改性表明程序容易修改的程度 。