【正文】 ???? 模型指明，如果使用了不好的軟件開發(fā)方法（未按軟件工程要求做），原來參加開發(fā)的人員或小組不能參加維護，則工作量（及成本）將按指數(shù)級增加。 ? 雖然不要求建立一個正式的維護機構(gòu)，但是在開發(fā)部門確立一個非正式的維護機構(gòu)則是非常必要的。 ? 在維護之前，就把責(zé)任明確下來，可以減少維護過程中的混亂。 ? 維護申請報告將由 維護管理員 和系統(tǒng)監(jiān)督員 來研究處理。 在每次軟件維護任務(wù)完成后進行情況評審，對以下問題做一總結(jié)： (1) 在目前情況下，設(shè)計、編碼、測試中的哪一方面可以改進 ? (2) 哪些維護資源應(yīng)該有但沒有 ? (3) 工作中主要的或次要的障礙是什么 ? (4) 從維護申請的類型來看是否應(yīng)當(dāng)有預(yù)防性維護 ? 情況評審對將來的維護工作如何進行會產(chǎn)生重要的影響。 ? 每次程序運行時的平均出錯次數(shù)； ? 花費在每類維護上的總“人時”數(shù)； ? 每個程序、每種語言、每種維護類型的程序平均修改次數(shù)； ? 因為維護，增加或刪除每個源程序語句所花費的平均“人時”數(shù)； ? 用于每種語言的平均“人時”數(shù)； ? 維護申請報告的平均處理時間； ? 各類維護申請的百分比。 ? 分析和理解程序 ? 修改程序 ? 重新驗證程序 分析和理解程序 ? 經(jīng)過分析， 全面、準確、迅速地理解程序是決定維護成敗和質(zhì)量好壞的關(guān)鍵 。若過程 i 調(diào)用過程 j，則 D[i][j]＝ 1，否則 D[i][j]＝ 0。 可獲得 有關(guān)數(shù)據(jù)在過程間如何傳遞 ，在過程內(nèi)如何處理 等信息。 4. 充分閱讀和使用源程序清單和文檔 ，分析現(xiàn)有文檔的合理性。 1. 設(shè)計程序的修改計劃 程序的修改計劃要考慮人員和資源的安排。 通常，可采用自頂向下的方法， 在理解程序的基礎(chǔ)上， (1) 研究程序的各個模塊、模塊的接口、及數(shù)據(jù)庫 ，從全局的觀點，提出修改計劃。用戶的某些業(yè)務(wù)因軟件中發(fā)生問題而中斷，為不讓系統(tǒng)長時間停止運行，需把問題局部化， 在可能的范圍內(nèi)繼續(xù)開展業(yè)務(wù) 。 ? 在修改源代碼時，都可能引入錯誤。 ? 容易導(dǎo)致設(shè)計與數(shù)據(jù)不相容的錯誤可以有： ? 重新定義局部的或全局的常量 ? 重新定義記錄或文件的格式 ? 增大或減小一個數(shù)組或高層數(shù)據(jù)結(jié)構(gòu)的大小 ? 修改全局或公共數(shù)據(jù) ? 重新初始化控制標志或指針 ? 重新排列輸入／輸出或子程序的參數(shù) ? 數(shù)據(jù)副作用可以通過 交叉引用表 加以控制。使得 軟件文檔不能反映軟件的當(dāng)前狀態(tài) 。 ? 過時的文檔內(nèi)容、索引和文本可能造成沖突，引起用戶失敗和不滿。 重新驗證程序 ? 在將修改后的程序提交用戶之前，需要進行 充分的確認和測試 ，以保證整個修改后程序的正確性。 ? 計算機確認 在進行了以上確認的基礎(chǔ)上，用計算機對修改程序進行確認測試： (1) 確認測試順序 ：先對修改部分進行測試，然后隔離修改部分，測試程序的未修改部分，最后再把它們集成起來進行測試。 (4) 在重新確認過程中，需邀請用戶參加 。 ? 許多維護要求并不是因為程序中出錯而提出的，而是為 適應(yīng)環(huán)境變化 或 需求變化 而提出的。 ? 軟件的 可維護性 是 軟件開發(fā)階段各個時期的關(guān)鍵目標 。 ? 為使每一個質(zhì)量特性都達到預(yù)定的要求，需要在軟件開發(fā)的各個階段采取相應(yīng)的措施加以保證。 ? 常用的度量一個可維護的程序的七種特性的方法。 ? 由于許多質(zhì)量特性是相互抵觸的，要 考慮幾種不同的度量標準 ，相應(yīng)地去度量不同的質(zhì)量特性。 ? 關(guān)于可靠性，度量的標準主要有： ? 平均失效間隔時間 MTTF ? 平均修復(fù)時間 MTTR ? 有效性 A = MTBD/(MTBD+MDT) 度量可靠性的方法 ? 根據(jù)程序錯誤統(tǒng)計數(shù)字，進行可靠性預(yù)測 。因此可用復(fù)雜性預(yù)測出錯率。而且設(shè)計合用的測試用例，取決于對程序的全面理解。 ? 通用性是指程序適用于各種功能變化而無需修改。 ? 設(shè) C是程序中各個模塊的平均復(fù)雜性， n是必須修改的模塊數(shù)， A 是要修改的模塊的平均復(fù)雜性。 ? 用于可移植性度量的檢查項目如下： ? 是否是用高級的獨立于機器的語言來編寫程序 ? ? 是否使用廣泛使用的標準化的程序設(shè)計語言來編寫程序 ? 是否僅使用了這種語言的標準版本和特性 ? ? 程序中是否使用了標準的普遍使用的庫功能和子程序 ? ? 程序中是否極少使用或根本不使用操作系統(tǒng)的功能 ? ?程序在執(zhí)行之前是否初始化內(nèi)存 ? ? 程序在執(zhí)行之前是否測定當(dāng)前的輸入／輸出設(shè)備 ? ? 程序是否把與機器相關(guān)的語句分離了出來，集中放在了一些單獨的程序模塊中，并有說明文件 ? ? 程序是否結(jié)構(gòu)化 ? 并允許在小一些的計算機上分段 (覆蓋 )運行 ? ? 程序中是否避免了依賴于字母數(shù)字或特殊字符的內(nèi)部位表示 ? 6. 效率 ? 效率表明一個程序能執(zhí)行預(yù)定功能而又不浪費機器資源的程度 。 ? 用于可使用性度量的檢查項目如下： ? 程序是否具有自描述性 ? ? 程序是否能始終如一地按照用戶的要求運行 ? ? 程序是否讓用戶對數(shù)據(jù)處理有一個滿意的和適當(dāng)?shù)目刂?? ? 程序是否容易學(xué)會使用 ? ? 程序是否使用數(shù)據(jù)管理系統(tǒng)來自動地處理事務(wù)性工作和管理格式化、地址分配及存儲器組織。 ? 要實現(xiàn)這所有的目標，需要付出很大的代價，而且也不一定行得通。例如，對編譯程序來說，可能強調(diào)效率；但對管理信息系統(tǒng)來說，則可能強調(diào)可使用性和可修改性。 ? 每個程序變量只用于唯一的程序目的，而且變量的作用范圍應(yīng)是明確的、有限制的。 進行明確的質(zhì)量保證審查 ? 質(zhì)量保證審查 對于 獲得和維持軟件的質(zhì)量 ，是一個很有用的技術(shù)。 ? 檢查的目的是要證實，已開發(fā)的軟件 是否符合標準 ， 是否滿足規(guī)定的質(zhì)量需求 。對每個模塊可用 McCabe環(huán)路來計算模塊的復(fù)雜性，若大于 10，則需重新設(shè)計。 ? 驗收檢查必須遵循的最小驗收標準。 (3) 源代碼標準 ① 盡可能使用最高級的程序設(shè)計語言，且只使用語言的標準版本； ② 所有的代碼都必須具有良好的結(jié)構(gòu)； ③ 所有的代碼都必須文檔化，在注釋中說明它的輸入、輸出、以及便于測試／再測試的一些特點與風(fēng)格。 ? 軟件在運行期間進行修改，會導(dǎo)致軟件質(zhì)量有變壞的危險，破壞程序概念的完整性。 ? 對于改變的原因應(yīng)當(dāng)進行分析 。 ? 使用單位的維護人員首先要仔細分析、研究賣主提供的用戶手冊、操作手冊、培訓(xùn)教程等，以及賣方提供的驗收測試報告等。 ? 根據(jù)測試結(jié)果，檢查和驗證軟件包的參數(shù)或控制結(jié)構(gòu)，以完成軟件包的維護。 ? 對于程序維護人員來說，要想 按程序編制人員的意圖重新改造程序 ，并對今后變化的可能性進行估計，缺了文檔是不行的。 ? 歷史文檔有三種： ? 系統(tǒng)開發(fā)日志 ? 錯誤記載 ? 系統(tǒng)維護日志