軟體維護概述

---

---

軟體維護如今已成為SDLC中廣泛接受的一部分。它代表軟體產品交付後所做的所有修改和更新。修改的原因有很多，其中一些簡要介紹如下。

• 市場狀況 - 隨著時間的推移而變化的政策，例如稅收和新引入的約束條件（例如，如何維護簿記），可能會觸發修改的需求。

• 客戶需求 - 隨著時間的推移，客戶可能會要求軟體中新增新功能。

• 主機修改 - 如果目標主機的任何硬體和/或平臺（例如作業系統）發生變化，則需要更改軟體以保持適應性。

• 組織變革 - 如果客戶端發生任何業務層面的變化，例如組織規模縮減、收購另一家公司、組織進軍新業務，則可能需要修改原始軟體。

維護型別

在軟體生命週期中，維護型別可能因其性質而異。它可能只是一些使用者發現的錯誤的例行維護任務，也可能根據維護規模或性質本身就是一個重大事件。以下是根據其特徵的一些維護型別。

• 糾正性維護 - 這包括為了糾正或修復由使用者發現或由使用者錯誤報告得出的問題而進行的修改和更新。

• 適應性維護 - 這包括應用的修改和更新，以使軟體產品保持最新狀態並適應不斷變化的技術和商業環境。

• 完善性維護 - 這包括為了使軟體在較長時間內保持可用而進行的修改和更新。它包括新功能、新的使用者需求，以改進軟體並提高其可靠性和效能。

• 預防性維護 - 這包括進行修改和更新以防止軟體的未來問題。其目的是解決目前不重要但將來可能導致嚴重問題的問題。

維護成本

報告表明，維護成本很高。一項關於估算軟體維護成本的研究發現，維護成本高達整個軟體過程週期成本的67%。

平均而言，軟體維護成本佔所有SDLC階段的50%以上。有多種因素導致維護成本居高不下，例如

影響維護成本的現實因素

• 任何軟體的標準使用年限被認為是10到15年。
• 較舊的軟體，旨在在記憶體和儲存容量較小的慢速機器上執行，無法在現代硬體上與新推出的增強型軟體相抗衡。
• 隨著技術的進步，維護舊軟體變得越來越昂貴。
• 大多數維護工程師都是新手，並使用試錯法來糾正問題。
• 通常，所做的更改很容易損害軟體的原始結構，從而使任何後續更改變得困難。
• 更改通常沒有記錄，這可能會在將來導致更多衝突。

影響維護成本的軟體端因素

• 軟體程式結構
• 程式語言
• 對外部環境的依賴性
• 員工可靠性和可用性

維護活動

IEEE為順序維護過程活動提供了一個框架。它可以以迭代方式使用，並且可以擴充套件，以便可以包含自定義專案和流程。

這些活動與以下每個階段密切相關

• 識別與跟蹤 - 它涉及識別修改或維護需求的活動。它由使用者生成，或者系統本身可能透過日誌或錯誤訊息進行報告。在此，還對維護型別進行分類。

• 分析 - 分析修改對系統的影響，包括安全影響。如果可能的影響嚴重，則尋找替代解決方案。然後將一組所需的修改具體化為需求規範。分析修改/維護的成本並得出估計值。

• 設計 - 根據上一階段設定的需求規範，設計需要替換或修改的新模組。建立測試用例以進行驗證。

• 實現 - 在設計步驟中建立的結構化設計的幫助下對新模組進行編碼。每個程式設計師都應並行進行單元測試。

• 系統測試 - 在新建立的模組之間進行整合測試。還在新模組和系統之間進行整合測試。最後，按照迴歸測試程式對整個系統進行測試。

• 驗收測試 - 在內部測試系統後，在使用者的幫助下對其進行驗收測試。如果在此狀態下，使用者抱怨一些問題，則會解決這些問題或記錄下來以便在下次迭代中解決。

• 交付 - 驗收測試後，系統將透過小型更新包或全新安裝系統的方式部署到整個組織。在軟體交付後，最終測試將在客戶端進行。

  如果需要，除了使用者手冊的紙質副本外，還提供培訓設施。

• 維護管理 - 配置管理是系統維護的重要組成部分。它藉助版本控制工具來控制版本、半版本或補丁管理。

軟體再工程

當我們需要更新軟體以使其保持當前市場水平，而不會影響其功能時，這稱為軟體再工程。這是一個徹底的過程，其中軟體的設計發生變化並且程式被重寫。

遺留軟體無法與市場上最新的技術保持同步。隨著硬體變得過時，軟體更新變得令人頭疼。即使軟體隨著時間的推移而老化，其功能也不會消失。

例如，最初 Unix 是用匯編語言開發的。當 C 語言出現時，Unix 被用 C 重構，因為用匯編語言工作很困難。

除此之外，有時程式設計師會注意到軟體的某些部分比其他部分需要更多的維護，並且也需要進行再工程。

再工程過程

• 確定要再工程的內容。是整個軟體還是其中一部分？
• 執行逆向工程，以獲取現有軟體的規範。
• 如果需要，重構程式。例如，將面向函式的程式更改為面向物件的程式。
• 根據需要重構資料。
• 將前向工程概念應用於獲取再工程軟體。

在軟體再工程中使用了一些重要的術語

逆向工程

它是一個透過徹底分析和理解現有系統來實現系統規範的過程。此過程可以看作是反向SDLC模型，即我們嘗試透過分析較低抽象級別來獲得較高抽象級別。

現有系統是先前實現的設計，我們對此一無所知。然後，設計人員透過檢視程式碼並嘗試獲取設計來進行逆向工程。有了設計，他們試圖得出規範。因此，從程式碼反向到系統規範。

程式重構

它是一個重構和重建現有軟體的過程。它完全是關於重新排列原始碼，無論是在相同的程式語言中還是從一種程式語言更改為另一種程式語言。重構可以包括原始碼重構和資料重構，或者兩者兼而有之。

重構不會影響軟體的功能，但會增強可靠性和可維護性。可以更改或更新經常導致錯誤的程式元件。

可以透過重構消除軟體對過時硬體平臺的依賴性。

前向工程

前向工程是從手頭的規範中獲取所需軟體的過程，這些規範是透過逆向工程獲得的。它假設過去已經進行了一些軟體工程。

前向工程與軟體工程過程相同，只有一點區別——它始終在逆向工程之後執行。

元件可重用性

元件是軟體程式程式碼的一部分，它在系統中執行獨立的任務。它可以是一個小模組或子系統本身。

示例

Web 上使用的登入過程可以被視為元件，軟體中的列印系統可以被視為軟體的元件。

元件具有很高的功能內聚性和較低的耦合率，即它們獨立工作並且可以在不依賴其他模組的情況下執行任務。

在OOP中，物件的設計非常具體，並且在其他軟體中使用的可能性較小。

在模組化程式設計中，模組被編碼以執行特定任務，這些任務可以在許多其他軟體程式中使用。

有一個全新的垂直領域，它基於軟體元件的重用，被稱為基於元件的軟體工程（CBSE）。

重用可以在不同的層級進行

• 應用級 - 將整個應用程式用作新軟體的子系統。

• 元件級 - 使用應用程式的子系統。

• 模組級 - 重用功能模組。

  軟體元件提供介面，可用於在不同元件之間建立通訊。

重用過程

可以採用兩種方法：要麼保持需求不變並調整元件，要麼保持元件不變並修改需求。

• 需求規格說明 - 在現有系統、使用者輸入或兩者結合的幫助下，指定軟體產品必須符合的功能和非功能需求。

• 設計 - 這也是標準的SDLC過程步驟，其中需求以軟體術語定義。建立整個系統及其子系統的基本架構。

• 指定元件 - 透過研究軟體設計，設計人員將整個系統劃分為更小的元件或子系統。一個完整的軟體設計變成了大量元件協同工作的一個集合。

• 搜尋合適的元件 - 設計人員參考軟體元件庫，根據功能和預期的軟體需求搜尋匹配的元件。

• 整合元件 - 將所有匹配的元件打包在一起，形成完整的軟體。