【正文】 以完整的軟件配置為基礎的結構化維護，是在軟件開發(fā)過程中應用軟件過程方法學的結果。 ?不能及時安排 ，使得客戶不滿意； ? 變更的結果 引入新的故障 ，使軟件整體質量下降 ? 把軟件人員抽調到維護工作中，干擾了軟件開發(fā) ?軟件維護的 代價 是 降低了生產率 ，在做老程序的維護時非常明顯。 ?模型指明，如果使用了不好的軟件開發(fā)方法（未按軟件工程要求做），原來參加開發(fā)的人員或小組不能參加維護，則工作量（及成本）將按指數(shù)級增加。 ?如果僅有程序代碼沒有文檔，則會出現(xiàn)嚴重的問題 ?需要維護的軟件往往沒有合格的文檔，或者文檔資料顯著不足。 ? 絕大多數(shù)軟件在設計時沒有考慮將來的修改。 ? 上述種種問題在現(xiàn)有的沒采用軟件過程思想開發(fā)出來的軟件中，都或多或少地存在著。 ?維護申請 提交給 維護管理員 ，他把申請交給某個 系統(tǒng)監(jiān)督員 去 評價 。 ?用戶必須 完整地說明產生錯誤的情況 ，包括 輸入數(shù)據(jù) 、 錯誤清單 以及 其它有關材料 。 ?修改報告提交修改負責人批準后才能開始進一步安排維護工作。 軟件維護過程 20 維護評價 ?評價維護活動比較困難 ，因為缺乏可靠的數(shù)據(jù)。 軟件維護過程 21 ?許多軟件的維護十分困難，原因在于這些 軟件的文檔不全 、質量差 、 開發(fā)過程不注意采用好的方法 ， 忽視程序設計風格 等。 ?維護人員理解、改正、改動或改進這個軟件的難易程度。 ?目前廣泛使用的是用如下的七個特性來衡量程序的可維護性。 ?這些質量要求要滲透到而各開發(fā)階段的各個步驟當中 。就是 質量檢查表、 質量測試、 質量標準 ?質量檢查表 是用于測試程序中某些質量特性是否存在的一個問題清單。 軟件可維護性 25 . 可理解性 ?可理解性表明人們通過閱讀源代碼和相關文檔，了解程序功能及其如何運行的容易程度。常用方法是利用一些 可靠性模型 ， 根據(jù)程序測試時發(fā)現(xiàn)并排除的錯誤數(shù)預測平均失效間隔時間 MTTF。程序復雜性度量標準可用于 預測哪些模塊最可能發(fā)生錯誤 ，以及 可能出現(xiàn)的錯誤類型 。 ?一個可測試的程序應當是 可理解的 ， 可靠的 ， 簡單的 。 ?靈活性是指能夠容易地對程序進行修改。 則修改的難度 D由下式計算： D = A / C . 可移植性 ?可移植性表明程序轉移到一個新的計算環(huán)境的可能性的大小 。 ?這些機器資源包括 內存容量 、 外存容量 、 通道容量 和 執(zhí)行時間 。 ? 程序是否具有容錯性 ? ? 程序是否靈活 ? 軟件可維護性 33 其它間接定量度量可維護性的方法 ?問題識別的時間； ?因管理活動拖延的時間； ?收集維護工具的時間； ?分析、診斷問題的時間； ?修改規(guī)格說明的時間； ?具體的改錯或修改的時間； ?局部測試的時間； ?集成或回歸測試的時間； ?維護的評審時間； ?這些數(shù)據(jù)反映了維護全過程中 檢錯－糾錯－驗證 的周期，即 從檢測出軟件存在的問題開始至修正它們并經回歸測試驗證這段時間 。 ?某些質量特性是相互促進的 ，例如可理解性和可測試性、可理解性和可修改性。 ?應當對程序的質量特性，在 提出目標 的同時還必須 規(guī)定它們的優(yōu)先級 。 提高可維護性的方法 37 ?使用結構化程序設計技術，提高現(xiàn)有系統(tǒng)的可維護性 ? 采用備用件的方法 ── 用一個新的結構良好的模塊替換掉整個要修改的模塊。 ?審查 用來 檢測在開發(fā)和維護階段內發(fā)生的質量變化 。在不同的檢查點，檢查的重點不完全相同。 ?可以使用各種 質量特性檢查表 ，或用 度量標準 來檢查可維護性。 (1) 需求和規(guī)范標準 ① 需求應當以可測試的術語進行書寫，排列優(yōu)先次序和定義； ② 區(qū)分必須的、任選的、將來的需求； ③ 包括對系統(tǒng)運行時的計算機設備的需求；對維護、測試、操作、以及維護人員的需求；對測試工具等的需求。 (4) 文檔標準 文檔中應說明： 程序的輸入／輸出、 使用的方法／算法、 錯誤恢復方法、 所有參數(shù)的范圍、 缺省條件等。 ?必須 定期檢查 ，對軟件做周期性的維護審查， 以跟蹤軟件質量的變化 。 提高可維護性的方法 43 3 .4. 對軟件包進行檢查 ?軟件包 是一種 標準化 的，可 為不同單位 、 不同用戶使用 的軟件。 ? 在此基礎上，深入 了解本單位的希望和要求 ， 編制軟件包的檢驗程序 。 機器語言 匯編語言 高級語言 (FORTRAN COBOL等 ) 查詢語言 表生成語言 圖象語言 應用生成語言 提高可維護性的方法 45 改進程序的文檔 文檔是影響軟件可維護性的決定因素。 ?另外，在軟件維護階段，利用 歷史文檔 ，可以大大簡化維護工作。預防性維護定義為： 把今天的方法學應用到昨天的軟件系統(tǒng)上，以支持明天的需求。 ?在某些情況下，這些活動按照圖中所示次序以線性順序進行，但也并非總是如此，例如，可能在文檔重構之前需要先進行逆向工程，以理解程序的工作原理。然后合理地分配再工程所需要的資源。 軟件再工程過程 51 3. 逆向工程 ?軟件的逆向工程是，分析程序以便在比源程序更高的抽象層次上創(chuàng)建出程序的某種描述的過程，也就是說，逆向工程是一個恢復設計結果的過程。 ?如果重構擴展到模塊邊界之外并涉及軟件體系結構，則重構變成了正向工程。 6. 正向工程： 正向工程也稱為更新或再造。 ? 改正性維護： 在軟件交付使用后，為了 識別和糾正由于軟件開發(fā)時隱藏的錯誤、改正軟件性能上的缺陷，軟件 進行的診斷和改正錯誤的過程就。進而以 擴充軟件功能 、 增強軟件性能 、改進加工效率 、 提高軟件的可維護性的 維護活動 ? 預防性維護： 為了 提高軟件的可維護性 、 可靠性等， 采用先進的軟件工程方法對需要維護的軟件或軟件中的某一部分（重新）進行設計、編制和測試。 (2)測試完程序后，刪去程序中的注解以縮短源程序長度。 (6)盡可能利用硬件特點以提高程序效率。 (10)用數(shù)據(jù)庫系統(tǒng)代替文件系統(tǒng)來存儲需要長期保存的信息 軟件工程中的一些觀念討論 55 (11)用 CASE環(huán)境或程序自動生成工具來自動生成一部分程序。 (15)把與硬件及操作系統(tǒng)有關的代碼放到某些特定的程序模塊中。 你將選取哪兩份文檔？為什么這樣選?。? 4．當一個十幾年前開發(fā)出的程序還在為其用戶完成關鍵的業(yè)務工作時，是否有必要對它進行再工程？如果對它進行再工程，經濟上是否劃算？ 5．代碼重構與正向工程有何相同之處？有何不同之處？ 作業(yè) 57 演講完畢，謝謝觀看！