软件维护
软件工程中的软件维护是交付后软件产品的修改以纠正故障，以提高性能或其他属性。
对维护的一个普遍看法是，它仅涉及解决缺陷。但是，一项研究表明，超过80％的维护工作用于非校正动作。用户提交问题报告的用户使这种看法永久存在，即实际上是系统的功能增强。最近的研究使固定比例接近21％。
历史
梅尔·雷曼（ Meir M.他的研究的主要发现得出的结论是，维护确实是进化的发展，并且通过了解随着时间的推移会发生的系统（和软件）的方式来帮助维护决策。雷曼（Lehman）证明，随着时间的流逝，系统继续发展。随着它们的发展，它们会变得更加复杂，除非采取某些诸如代码重构之类的动作来降低复杂性。在1970年代后期，Lientz和Swanson的一项著名且广泛引用的调查研究揭示了维护所支出的很高的生命周期成本。
调查显示，在前两种类型的维护工作中，约有75％的努力，错误校正消耗了约21％。随后的许多研究表明了类似的问题级。研究表明，在新需求数据收集和分析中，最终用户的贡献至关重要。这是在软件演变和维护过程中出现任何问题的主要原因。软件维护很重要，因为它消耗了整体生命周期成本的很大一部分，并且无法快速而可靠地更改软件，这意味着损失了商机。
软件维护的重要性
关键的软件维护问题是管理和技术。管理问题包括与客户优先事项的一致性，人员配备，分配职责和估算成本。技术问题包括：有限的理解，影响分析，测试和可维护性测量。
软件维护是一项广泛的活动，包括误差校正，功能增强，删除过时的功能和优化。因为变化是不可避免的，因此必须开发机制以进行评估，控制和进行修改。
部署后在软件上完成的任何工作都被视为维护。维护随着时间的推移保留了软件的价值。可以通过扩展客户群，满足新的和其他要求，更易于使用，更高效并采用更新的技术来增强价值。维护可能跨越数十年，而初始发展通常不到3年。
软件维护计划
软件的一个不可或缺的一部分是维护，它需要在软件开发过程中构建准确的维护计划。它应该指定用户如何请求修改或报告问题。预算应包括资源和成本估算，应为开发每个新系统功能及其质量目标的开发做出新的决定。在开发过程之后，软件维护可以持续5年以上（甚至几十年），呼吁制定有效的计划，该计划可以解决软件维护范围，剪裁后交付/部署过程，指定谁将提供维护，并对生命周期成本进行估计。
软件维护过程
本节将六个软件维护过程描述为：
- 实施 - 软件准备和过渡活动，例如制定维护计划；在开发过程中确定的处理问题的准备；以及产品配置管理的后续。
- 问题和修改分析 - 确认（复制），分析和研究的请求和问题。提出并记录了解决方案。获得了应用修改的授权。
- 修改实现 - 软件代码，数据和/或配置已更新，编译和重新部署。
- 修改接受 - 提交请求的个人操作/测试软件以确认问题已解决。
- 迁移（例如，平台迁移）是例外，并且不是日常维护任务的一部分。如果必须将软件移植到另一个平台而没有任何功能上的任何更改，则将使用此过程，并且可能将维护项目团队分配给该任务。
- 过时/替换软件组件的退休。这通常不会每天发生。
例如，维护者独有的过程，活动和实践是：
- 过渡：一个受控和协调的活动序列，在此过程中，系统将从开发人员逐渐转移到维护者。理想情况下，它应该包括一个知识转移（KT），以便在典型的手工抛弃过程中发生。
- 服务水平协议（SLA）和由维护者协商的专业（特定领域）维护合同
- 修改请求和问题报告帮助台：维护人员使用的问题处理过程，以优先，文档和路由请求。
软件维护类别
EB Swanson最初确定了三类维护：纠正，适应性和完美。 IEEE 1219标准在2010年6月被P14764取代。此后已更新和ISO/IEC 14764礼物：
- 纠正性维护：交付后执行的软件产品的反应性修改以纠正发现的问题。自动错误修复可以自动化纠正性维护。
- 自适应维护：修改交付后执行的软件产品，以使软件产品可在变化或变化的环境中使用。
- 完美维护：交付后修改软件产品以提高性能或可维护性。
- 预防性维护：交付后的软件产品修改，以检测并纠正软件产品中的潜在故障，然后才能有效故障。
还有一个预先交付/预发行前维护的概念，这是您所做的所有好事，以降低软件的总拥有成本。符合包括软件可维护目标的编码标准之类的东西。软件的耦合和凝聚力的管理。实现软件支持性目标（例如，SAE JA1004，JA1005和JA1006）。一些学术机构正在进行研究以量化正在进行的软件维护成本，因为缺乏资源，例如设计文档以及系统/软件理解培训和资源（在没有可用设计数据的情况下，成本乘以大约1.5-2.0） 。
维护因素
关键调整因子对维护的影响（按最大积极影响顺序排序）
| 维护因素 | 加上范围 |
|---|---|
| 维护专家 | 35% |
| 高员工经验 | 34% |
| 台式变量和数据 | 33% |
| 基本代码的复杂性低 | 32% |
| Y2K和特殊搜索引擎 | 30% |
| 代码重组工具 | 29% |
| 重新设计工具 | 27% |
| 高级编程语言 | 25% |
| 逆向工程工具 | 23% |
| 复杂性分析工具 | 20% |
| 缺陷跟踪工具 | 20% |
| Y2K“大规模更新”专家 | 20% |
| 自动更改控制工具 | 18% |
| 无薪加班 | 18% |
| 质量测量 | 16% |
| 正式的基本法规检查 | 15% |
| 回归测试库 | 15% |
| 良好的响应时间 | 12% |
| 年度培训> 10天 | 12% |
| 高管理经验 | 12% |
| 服务台自动化 | 12% |
| 无犯错的容易模块 | 10% |
| 在线缺陷报告 | 10% |
| 生产力测量 | 8% |
| 易用的易用性 | 7% |
| 用户满意度测量 | 5% |
| 高团队士气 | 5% |
| 和 | 503% |
不仅容易发生错误的模块麻烦，而且它们也会降低性能。例如，非常复杂的意大利面条代码很难安全地维护。经常降低性能的非常普遍的情况是缺乏合适的维护工具，例如缺陷跟踪软件，更改管理软件和测试库软件。下面描述了一些因素和对软件维护的影响范围。
关键调整因素对维护的影响（按最大负面影响顺序排序）
| 维护因素 | 减去范围 |
|---|---|
| 犯错的容易模块 | -50% |
| 嵌入式变量和数据 | -45% |
| 员工没有经验 | -40% |
| 高码复杂性 | -30% |
| 没有特殊搜索引擎的Y2K | -28% |
| 手动更改控制方法 | -27% |
| 低级编程语言 | -25% |
| 没有缺陷跟踪工具 | -24% |
| 无Y2K“大规模更新”专家 | -22% |
| 易于使用的易用性 | -18% |
| 没有质量测量 | -18% |
| 没有维护专家 | -18% |
| 响应时间差 | -16% |
| 没有代码检查 | -15% |
| 没有回归测试库 | -15% |
| 没有帮助台自动化 | -15% |
| 没有在线缺陷报告 | -12% |
| 管理不足 | -15% |
| 没有代码重组工具 | -10% |
| 没有年度培训 | -10% |
| 没有重新设计工具 | -10% |
| 没有反向工程工具 | -10% |
| 没有复杂性分析工具 | -10% |
| 没有生产力测量 | -7% |
| 贫穷的团队士气 | -6% |
| 没有用户满意度测量 | -4% |
| 没有加班时间 | 0% |
| 和 | -500% |
维护债务
在2019年第27届国际软件质量管理会议上的论文中，约翰·埃斯代尔（John Estdale）介绍了“维护债务”一词，以实现实施对外部IT因素（例如图书馆，平台和工具）产生的维护需求，这些需求已变得过时。该申请继续运行，IT部门忘记了这一理论责任，重点关注其他地方的更紧急要求和问题。随着时间的流逝，这种债务积累了，默默地吞噬了软件资产的价值。最终发生了一些使系统变化不可避免的事情。
然后，所有者可能会发现系统无法再修改 - 从字面上看，它是无法实现的。不太明显的是，维护解决业务问题可能需要太长或花费太多，并且必须找到替代解决方案。该软件突然崩溃了0英镑的价值。
埃斯特代尔（Estdale）将“维护债务”定义为：应用程序的当前实施状态与理想之间的差距，仅使用完全维护和支持的外部组件的功能。这种债务通常是隐藏的或没有承认的。应用程序的整体可维护性取决于其他供应商的各种组件的持续可获得性，包括：
- 开发工具：来源编辑，配置管理，编译和构建
- 测试工具：测试选择，执行/验证/报告
- 执行以上操作的平台：硬件，操作系统和其他服务
- 生产环境和任何待机/灾难恢复设施，包括源代码语言的运行时间支持环境，以及更广泛的作业计划生态系统，文件传输，复制存储，备份和档案，单登录等。
- 单独获取的软件包，例如DBM，图形，通讯，中间件
- 以源代码，对象代码库和其他不可置能的服务购买
- 其他应用程序共享生产环境或与该应用程序互动的任何要求
而且当然
- 相关技能，内部或市场的可用性。
组件的完全消失可能会使应用程序无法重建，或者无天生。