软件维护

软件维护的软件工程是一个软件产品的交付，以正确的故障后的修改，以提高性能或其他属性。

对维护的普遍看法是，它仅涉及修复缺陷。然而，一项研究表明，超过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）。