軟件維護的軟件工程是一個軟件產品的交付，以正確的故障后的修改，以提高性能或其他屬性。

對維護的普遍看法是，它僅涉及修復缺陷。然而，一項研究表明，超過80%的維護工作用于非糾正措施。用戶提交的問題報告實際上是對系統功能的增強，從而延續了這種看法。最近的研究表明修復錯誤的比例接近21%。

1969年，MeirM.Lehman首次提出了系統的軟件維護和演化問題。在二十多年的時間里，他的研究導致了雷曼定律的形成（Lehman1997）。他研究的主要發現得出的結論是，維護實際上是一種進化發展，并且通過了解系統（和軟件）隨著時間的推移會發生什么來幫助做出維護決策。雷曼兄弟證明了系統會隨著時間的推移而不斷發展。隨著它們的發展，它們會變得越來越復雜，除非采取一些措施（例如代碼重構）來降低復雜性。在1970年代后期，Lientz和Swanson進行的一項著名且被廣泛引用的調查研究揭示了生命周期成本中非常高的部分用于維護的費用。

調查顯示，大約75%的維護工作在前兩種類型上，糾錯消耗了大約21%。許多隨后的研究表明了類似的問題規模。研究表明，在新的需求數據收集和分析過程中，最終用戶的貢獻至關重要。這是軟件演化和維護過程中出現任何問題的主要原因。軟件維護很重要，因為它消耗了整個生命周期成本的很大一部分，而且無法快速可靠地更改軟件意味著失去商機。

關鍵的軟件維護問題既有管理方面的，也有技術方面的。關鍵管理問題是：與客戶優先事項保持一致、人員配備、由哪個組織進行維護、估算成本。關鍵技術問題是：理解有限、影響分析、測試、可維護性測量。

軟件維護是一項非常廣泛的活動，包括糾錯、功能增強、過時功能的刪除和優化。因為變化是不可避免的，所以必須建立評估、控制和修改的機制。

因此，在軟件運行后為更改軟件所做的任何工作都被視為維護工作。目的是隨著時間的推移保持軟件的價值。可以通過擴大客戶群、滿足額外要求、變得更易于使用、更高效和采用更新技術來提高價值。維護可能跨越20年，，而開發可能需要1-2年。

軟件的一個組成部分是維護，這需要在軟件開發過程中構建準確的維護計劃。它應該指定用戶將如何請求修改或報告問題。預算應包括資源和成本估算，并且應針對每個新系統功能及其質量目標的開發做出新的決定。軟件維護可以在開發過程后持續5年以上（甚至幾十年），需要一個有效的計劃來解決軟件維護的范圍、交付/部署后過程的剪裁、指定誰將提供維護，并估算生命周期成本。

1. 實施過程包含軟件準備和過渡活動，例如維護計劃的構思和創建；處理開發過程中發現的問題的準備；以及產品配置管理的后續工作。
2. 問題和修改分析過程，一旦應用程序成為維護組的責任就執行。維護程序員必須分析每個請求，確認它（通過再現情況）并檢查其有效性，調查它并提出解決方案，記錄請求和解決方案建議，最后，獲得應用修改所需的所有授權。
3. 考慮實施修改本身的過程。
4. 接受修改的過程，通過與提交請求的個人確認修改的工作，以確保修改提供了解決方案。
5. 遷移過程（例如平臺遷移）非常特殊，不是日常維護任務的一部分。如果必須將軟件移植到另一個平臺而不改變功能，則將使用此過程，并且可能會為該任務分配一個維護項目團隊。
6. 最后，最后一個維護過程，也是一個不會每天發生的事件，是一個軟件的退役。

有許多維護人員獨有的流程、活動和實踐，例如：

• 轉換：一個受控和協調的活動序列，在此期間系統逐漸從開發者轉移到維護者
• 由維護者協商的服務級別協議(SLA)和專門的（特定于域的）維護合同
• 修改請求和問題報告幫助臺：維護人員用來對他們收到的請求進行優先級排序、記錄和路由的問題處理過程

EBSwanson最初確定了三類維護：糾正性、適應性和完美性。所述的IEEE1219標準是由在2010年6月取代P14764。這些已經更新，ISO/IEC14764提出：

• 糾正性維護：交付后對軟件產品進行被動修改以糾正發現的問題。糾正性維護可以通過自動錯誤修復實現自動化。
• 適應性維護：在交付后對軟件產品進行修改，以保持軟件產品在變化或變化的環境中可用。
• 完善的維護：軟件產品在交付后修改以提高性能或可維護性。
• 預防性維護：在軟件產品交付后對軟件產品進行修改，以在軟件產品中的潛在故障成為有效故障之前對其進行檢測和糾正。

還有一個預交付/預發布維護的概念，這是您為降低軟件的總擁有成本所做的所有好事。諸如遵守包括軟件可維護性目標在內的編碼標準之類的事情。軟件耦合和內聚的管理。實現軟件可支持性目標（例如SAEJA1004、JA1005和JA1006）。一些學術機構[誰？]正在開展研究以量化由于缺乏設計文檔和系統/軟件理解培訓和資源等資源而導致的持續軟件維護成本（在沒有可用設計數據的情況下，將成本乘以約1.5-2.0）。