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