1 目的
维护过程 1的目的是维持系统提供理想服务的能力。
这一过程监控系统提供服务的能力，记录事件以供分析，采取纠正、适应、完善和预防措施，并确认恢复的能力。
对于软件系统，维护过程对已部署的软件系统和元素进行更正、更改和改进。对于可免费使用、广泛商业分布或在少数受控环境中运行的系统，软件系统的维护方法有所不同。
软件系统维护的需求可能由多种原因引起，除了潜在的系统缺陷之外，例如对接口系统或基础设施的更改、不断发展的安全威胁以及系统生命周期内系统元素和支持系统的技术过时。通常，功能的扩展、中期升级或遗留系统的演变会成为一个新的软件系统开发项目，将应用这一套95
在其他情况下，软件系统维护作为一系列连续的优先工作项执行，可能以工作量为基础。软件系统元素的维护可以包括硬件、软件和服务，如通信或 Web 服务。维护与配置管理流程和软件资产管理紧密相关，并与其他技术流程同时执行。
注：ISO/IEC/IEEE14764:2006软件工程 软件生命周期过程 维护和ISO/IEC16350，信息技术 2 系统与软件工程 应用管理提供了更多详细信息。SWEBOK， 软件工程知识体系指南， 软件维护知识领域讨论了软件维护基础知识、 关键问题、 测量、技术、维护过程和支持活动以及工具。该指南还讨论了支持软件可靠性的模型、 技术和措施。
2 结果
成功实施维护过程的结果是：
- 确定影响系统要求、 架构或设计的维护约束。
- 维护所需的任何支持系统或服务均可用。
- 提供更换、 修理或修订的系统要素。
- 报告需要进行变更以解决纠正、 完善或适应性维护的问题。
e)确定故障和寿命数据，包括相关成本。
3 活动和任务
项目应根据组织关于维护过程的适用政策和程序实施以下活动和任务。
a)准备维护。此活动包括以下任务：
1）定义维护策略，包括考虑以下几点：
我） 建立优先级 3、典型时间表和程序，以执行、验证、分发和安装符合操作可用性要求的软件维护变更；
二） 建立技术和方法以认识到纠正、适应和完善维护的需要；
三） 定期评估软件系统及其架构的发展设计特性；
四） 利用相关系统的技术变化信息预测组件和技术的潜在过时性；
五） 建立优先级和资源以获得正确版本的产品和执行维护所需的产品信息（例如，计划或分阶段安装、维护补丁或软件升级）；
维护措施将提供对性能水平、有效性和效率，包括获取历史故障和失败信息；
在问题解决期间对数据和系统中数据的影响的约定权利以及維護活動；
确保假冒或未经授权的系统元素不会被引入系统;
九） 维护变更对其他软件系统元素的影响与保留已报告的软件异常的风险；以及
- 考虑与健康和安全、保障和环境相关的法律和监管要求， 实现系统或软件修复或更换、修正、打补丁、更新和升级所需的技能和人员水平。
2）对于非软件元素，定义整个生命周期的物流策略，包括采购和运营考虑因素：要存储的替换元素的数量和类型、它们的存储位置和条件、它们的预期替换率以及它们的存储寿命和更新频率。
注意：在概念探索或开发阶段的早期就考虑了可支持性的影响。物流有助于确保在正确的地方提供正确数量和质量的必要材料和资源
以及整个部署和维持阶段的时间。
- 识别要纳入系统/软件需求、架构或设计的维护约束。
注：这些通常源于以下需求：1）重新使用现有的维护和验证支持系统；2）重新使用现有的可替换系统元素并适应重新供应的限制；3）在特定位置或环境中进行维护。例如，强调封装、模块化和可扩展性的软件架构和设计可以更易于维护。记录系统设计和构造的要求可以减少在需要维护时对系统和元素进行逆向工程所需的工作量。系统架构和设计反映了在解决问题期间回滚、备份和恢复数据的需要。使系统可用于远程诊断和维护的功能可以纳入架构和设计中。
4）确定交易，以便系统和相关维护和物流行动能够产生解决方案即可负担、可操作、可支持、可持续。
注意系统分析和决策管理流程用于执行评估和交易决策。
- 识别并规划支持维护所需的必要支持系统或服务。
注：这包括识别支持系统的要求和接口。维护支持系统的选择通常反映在初始系统实施期间重新使用现有或等效的设计、开发和配置管理基础架构的需要。
- 获取或获得将要使用的支持系统或服务的访问权。
注：验证过程 4用于客观确认维护支持系统是否实现了其预期用途和功能。
b)执行维护。此活动包括以下任务：
- 审查
利益相关者5的要求、投诉、事件、事故和问题报告，以确定纠正措施、适应性、完善性和预防性的维护需求。
- 审查
注意对于具有迭代生命周期的软件系统，变化的需求可被视为自适应和完善维护活动的来源。对于软件维护，此过程对已部署的软件进行更正、更改和改进，以及修补和更新以维护系统安全。
2）分析维护变化对数据结构、数据和相关软件功能、用户文档和接口的影响。
注意：审查和分析通常包括以下因素：维护行动的类别、修改的规模、所涉及的成本、修改时间以及对性能、安全或保障的影响。
3）当遇到意外故障导致软件系统崩溃时，恢复系统到运行状态。
注意：通常可以通过回滚、解决方法或识别并纠正故障原因来完全恢复到已降级的运行状态。如果完全恢复被延迟或不可能，系统将恢复到降级模式，与应急计划一致。如果可能，使用不同的环境复制故障
类似于操作环境，并确定故障的根本原因 6。调用配置管理流程，特别是发布管理活动来控制系统的计划和紧急更改。
4）执行纠正法律（缺陷）和错误的程序，或更换或升级系統元素。
注：纠正法律和错误需要使用问题解决方案，并且可以通过质量保证和项目评估和控制过程来处理。
注：通常，执行回归测试以验证维护变更未引入其他问题，即完整且正确地实施新的和修改后的需求，而不会影响原始未修改需求的性能。过渡过程 7可用于部署重大维护变更；小修复通常作为维护过程的一部分进行处理。记录操作以方便将来进行维护和解决问题，并用于可降解系统元素的后勤分析。
注：系统和数据恢复程序及维护信息通常存放在执行维护时可用的介质上。
5） 通过更换、修补、增强或升级软件系统元素来执行预防性维护，以提高预计达到不可接受的服务水平的软件系统的性能（例如，由于需求或存储数据的增加而导致容量不足），或避免不可接受的操作条件（例如，运行没有过时的安全软件）。
- 确定何时需要适应性或完善性维护。
注意适应性和完善性维护措施通常涉及改变系统/软件要求、架构和设计。可以启动一个新项目来修改现有的软件系统。
c)提供后勤支持。此项活动包括以下任务：
注：后勤行动使软件系统能够维持作战准备状态。 这些行动包括人员配备、供应支持、支持设备、技术数据需求 8（用户文档）和商定的数据权利、培训支持、通信、设备/计算资源支持和设施的规定。
1）获取资源以支持软件系统的整个生命周期或项目的整个生命周期（获取后勤）。
注：采购物流考虑因素包含在协议流程 9产生的协议中。这包括进行分析以确定对系统初始设计进行具有成本效益的变更，以提高可支持性和易于维护性，以及在使用/部署期间分发软件修复和升级的安排。
这些决策通常受到可用性要求的制约，并会影响供应链管理。
2）监控替换元件和支持系统的质量和可用性及其交付机制及其在存储期间的持续完整性。
注：运营物流涉及在整个运营生命周期内同时调整目标系统和支持系统，以帮助确保有效、高效地交付软件功能。它还包括熟练资源的可用性。例如，可靠的支持系统具有读取存储在以前媒体格式上的软件的能力，或者将备份文件迁移到当前媒体和当前维护的支持系统。
3）实现软件系统或元素分发的机制，包括打包、处理、物品在生命周期内所需的存储、通信或运输。
注：软件分发和安装通常是自动化的。软件包通常包括软件许可条款（包括数据权利）和软件资产管理元素。通常需要其他系统元素的物流规划来支持集成和过渡过程的目标。
注：考虑需要在现场或其他位置存储备用元素或软件备份，以根据需要维护软件系统功能（对于应急操作来说，可能处于降低的级别）。
4）确认物流行动满足软件系统或要素保障能力要求或实现已规划并实施作战准备。
注意这些后勤行动可以包括人员配备、供应支持、支持设备、技术数据需求（用户文档、说明、清单）、培训支持、通信、设备/计算资源支持和设施。
d)管理维护和物流的结果。此活动包括以下任务：
1）记录事件和问题，包括其解决方案，以及重大维护和后勤结果。
注：这包括由于维护策略、维护支持系统、维护和物流执行或不正确的系统定义而导致的异常。项目评估与控制和质量保证过程用于执行维护问题的识别和解决，例如，分析数据以确定根本原因、采取纠正或改进措施以及记录经验教训 10。此活动可以包括变更专家或软件分发程序。对软件系统需求、架构或设计的变更是在其他技术过程中完成的。
2）识别并记录事件、问题以及维护和物流行动的趋势。
注：趋势数据和问题解决报告用于通知操作和维护人员、客户以及其他创建或使用类似系统实体的利益相关者和项目。
注：事件和问题的报告（包括随后采取的措施）是通过质量保证过程的事件和过程管理活动进行跟踪的。
3)保持所维护的系统要素的可追溯性 11。
注意：记录的维护操作与软件系统元素和生命周期工件之间保持双向可追溯性。软件资产管理中的变更（例如软件许可证存储放置系统的分配）都会被记录下来。
- 提供已选定的基线关键工件和信息项。
注意配置管理流程用于建立和维护配置项和基线以及跟踪许可证和数据权利。此流程确定基线的候选者，信息管理流程控制信息项，例如维护程序。
- 监控和衡量客户对系统和维护支持的满意度。
注意：ISO10004:2012 包含监测和衡量客户满意度的指南。收集客户满意度数据后，将其用于质量管理流程。