大学软件工程导论《软件维护》复习课件

软件维护软件工程导论·期末复习2026年复习导览01维护认知概念、特点与成本意识02类型辨析四种维护类型与占比03过程实施维护组织、事件流与标准04可维护性定义与五大决定因素05工程化演进预防性维护与再工程01维护认知维护是软件生命周期中持续时间最长、投入最大的阶段维护是交付后才真正开始“软件交付使用后即进入生命周期最后一个阶段——软件维护。交付不是终点，维护才是软件生命的真正延续。”投入最大维护占整个生命周期的

60%~80%，持续时间最长——它才是软件生命的延续。软件维护的基本任务是保证软件在相当长时期内正常运行。维护占比占整个生命周期60%~80%持续时间最长维护≠只修Bug软件交付后，为改正错误而进行修改为适应环境变化而调整为满足新需求而扩充为提高质量而优化维护对象不只有程序代码维护对象：三位一体——程序、数据、文档协同维护程序、数据、文档三位一体，缺一不可程序：可执行代码最直观的维护对象数据：系统运行的基础须与程序同步更新文档：记录设计意图与实现细节缺一不可80%非纠正性活动完善性维护占比最高工作量真相维护重心不在修Bug80%非纠正性活动完善性维护占比最高触发点用户报告缺陷环境迁移功能扩展结构优化由来已久的软件工程背景1968年NATO会议首次提出软件工程概念，以系统化、规范化、可度量的过程化方法开发和维护软件。1993年IEEE定义权威定义核心定义：将系统化、规范、可度量的方法用于软件的开发、运行和维护过程。维护与开发、运行并列，是软件工程方法不可分割的组成部分维护并非游离于工程化之外的附属环节维护与开发、运行并列，是软件工程方法不可分割的组成部分维护成本为何居高不下维护是软件生命周期中经济分量最重的阶段。开篇判断维护是软件生命周期中经济分量最重的阶段。维护成本通常占软件总成本的60%～90%，远超开发投入。控制维护成本，是软件工程的核心目标之一。标准依据1项ISO/IEC/IEEE14764:2022维护成本通常占软件总成本的

60%～90%历史趋势2项1970年维护费用占总预算

35%～40%1990年升至

70%～80%，逐年攀升行业印证2项IT行业通用标准运维费用约占项目建设费

10%～20%中国软件行业基准数据CSBMK应用软件运维费用占比约

9.52%～9.89%，接近一成维护的特点与代价构成认识特点与代价，是理解结构化维护、可维护性与过程管理的认知前提。四大特点4项长期性贯穿软件使用全过程复杂性修改一处可能波及其他部分风险性修改可能引入新问题成本高维护成本常超过开发成本两类代价2类有形代价直接投入的人力与资源无形代价用户不满、引入潜在错误降低质量、开发过程混乱致生产率大幅下降02类型辨析错误修，环境适，功能完善，防未然四种维护类型一图总览按维护目的划分，软件维护共四种类型，各用一句话即可锁定辨析主线。修正性维护Corrective修复Bug——出了错，得修适应性维护Adaptive应对环境变化——环境变了，得改完善性维护Perfective增加或改进功能——想要新功能，得加预防性维护Preventive预防未来问题——提前改，防出事修正性维护修复已存缺陷1发现错误用户报告异常行为或监控发现故障2报告记录问题现象提交维护请求3分析审查缺陷现象复现并界定范围4定位原因追踪代码逻辑确定缺陷根源5修改代码实施修复方案更新程序版本6测试验证回归测试确认缺陷消除7发布修复部署补丁更新正式环境严重错误：立即紧急维护轻微错误：统筹排队处理适应性维护应对环境变化核心辨析：软件本身没有错，而是外部环境变了。

技术环境升级操作系统升级：Windows10→Windows11

合规性需求数据隐私法规更新：GDPR

依赖项变更运行环境升级：Java版本升级引发兼容问题

典型场景MySQL5.7升8.0

适配税务计算逻辑匹配新税法非功能性修改特征：非功能性修改，不改变核心功能，仅适配环境。适应性维护占维护工作量的

18%～25%完善性维护占比最大定义：增加新功能、改进已有功能或提升性能，满足用户"想要更好用"的需求。维护的主体重心不在修Bug，而在持续改进。定义增加新功能、改进已有功能或提升性能，满足用户“想要更好用”的需求。核心特征主动性：软件本身运行正常，但用户想要更好。触发条件用户需求扩展性能瓶颈代码重构需求典型场景为电商系统增加商品推荐算法；优化数据库查询语句以减少页面加载时间。50%～60%占维护工作总量IEEE统计可达50%～70%预防性维护着眼未来最易被忽视，也最常成为命题点。**定义**：预先修改软件，防止未来可能发生的错误或性能下降，关注长期可维护性。四种维护中唯一主动的类型由开发团队主导，用户通常无感知未雨绸缪，而非被动响应特征：前瞻性、技术驱动；短期投入大，长期显著减少维护成本。4%～5%占维护工作总量典型场景更新依赖库修复已知安全漏洞（如

Log4j漏洞升级）硬编码配置改为可配置参数添加自动化测试覆盖关键模块依托迭代消除隐患稳定基线四种维护占比与辨析口诀50%~70%完善性维护占比最高25%适应性维护20%修正性维护5%预防性维护占比最低占比排序完善性>适应性>修正性>预防性依据IEEE统计协作关系预防性维护可减少修正性维护需求完善性与适应性常伴随进行，如升级框架时同步优化功能辨析口诀错误修、环境适、功能完善、防未然先判断改的是什么，再对号入座易混点适配新分辨率→

适应性维护提升体验→

完善性维护03过程实施维护的本质是压缩了的软件定义与开发过程维护本质是压缩的开发过程维护过程是软件交付后，对维护请求进行处理、修改并验证效果的一系列有序活动。1常见误解误区认识接到需求→修改代码→上线，三步完成2实际本质正确认识维护是修改和压缩了的软件定义与开发过程理解本质，才能明白规范过程的必要性每次修改都经过评估和审批经过设计评审与测试验证变更历史完整可追溯维护组织与角色分工多数组织不设正式维护机构，但非正式维护机构非常必要。1申请→2评价→3修改→4审计各角色可个人或小组承担；开始维护前明确责任，能大幅减少过程混乱。维护管理员接收维护申请系统监督员评价申请修改负责人确定修改方式配置管理员把关修改范围、审计软件配置维护事件流的分流处理维护类型不同，修正性维护按错误严重程度分级，适应性/完善性维护按优先级排队。修正性维护严重立即分派，监督员指导下救火不严重按优先级与其他工作排队适应性/完善性维护先为每项申请确定优先级优先级高立即开展，其余排队统一安排共同技术工作修改需求说明修改设计代码修改单元测试集成测试确认测试配置评审维护事件流·分流处理01修正性·严重立即分派，监督员指导02修正性·不严重按优先级排队与其他工作统筹03适应性/完善性统一通道：确定优先级04优先级高立即开展，其余排队统一安排标准过程与国际规范ISO/IEC/IEEE14764:2022是软件维护领域的国际标准，由ISO与IEEE合作制定。六大核心活动维护准备问题与修改分析修改实施维护审查与验收迁移退役2022版更新新增性维护：区别于完善性维护，专指为系统添加新功能引入DevOps与敏捷实践：如某银行采用CI/CD管道进行频繁小规模交付维护信息系统运维六大过程日常运维缺陷诊断与修复配置管理变更管理系统恢复管理发布管理04可维护性文档是软件可维护性的决定性因素可维护性定义与五大因素可维护性：维护人员理解、改正、改进该软件的难易程度。可理解性UNDERSTANDABILITY理解软件结构、功能与接口的难易程度。可测试性TESTABILITY取决于理解程度、测试工具与程序复杂度。可修改性MODIFIABILITY软件容易修改的程度。可移植性PORTABILITY程序从一种计算环境转移到另一种环境的难易程度。文档是决定性因素两类文档，各司其职用户文档面向用户·回答“做什么”核心问题回答“做什么”功能描述安装手册参考手册操作员指南结构化维护具备完整文档与测试记录减少精力浪费，显著提高维护总体质量维护判据文档+测试=可估量、可回归系统文档面向开发者·回答“怎么做”核心问题回答“怎么做”设计实现测试非结构化维护唯一成分只有程序代码维护人员难以理解源程序改动后果难以估量，无法回归测试维护判据仅有代码=后果不可估量、不可回归可维护性复审贯穿全程可维护性若等到维护阶段才补救，代价高、见效晚。把功夫下在前面，才能在漫长的维护期持续受益把功夫下在前面，才能在漫长的维护期持续受益现状可维护性若等到维护阶段才补救，代价高、见效晚问题等到维护阶段才补救，代价高、见效晚做法开发与维护的每个阶段结束，都在技术审查和管理复查中，专门复审可维护性检查产出是否具备可理解性可测试性可修改性可移植性可重用性目标贯穿始终：开发期减少今后维护工作量，维护期继续保持可维护性提升可维护性的工程实践技术底座：以上实践共同构成可维护性保障的技术底座。代码重构冗余消除冗余代码条件简化条件判断模块模块化分层设计命名优化变量命名，提高可读性与复用性自动化测试框架借助

JUnit、Selenium

等框架目的高效验证代码改动的正确性CI/CD触发每次代码提交触发自动构建与测试保障确保新代码不影响已有功能代码评审发现发现问题、优化结构传承实现团队知识传递设计模式模式合理使用单例、工厂、观察者、策略等模式效果降低代码复杂度，提升系统灵活性与可维护性技术底座这些实践共同构成可维护性保障的技术底座。05工程化演进好的维护延长软件生命期预防性维护支撑长期演进预防性维护为提高软件可维护性、可靠性、为以后进一步改进软件打下良好基础。策略定位占比最小，却着眼长期把预防性维护当作策略而非应急手段，是维护思想成熟的标志。策策略定位目标提高软件可维护性、可靠性，为以后进一步改进软件打下良好基础。定义采用先进的软件工程方法，对需要维护的软件或其一部分重新进行设计、编制和测试。典型改造专用报表功能→通用报表生成功能当时看似增加投入使系统获得适应未来变化的能力，不被淘汰软件再工程应对老旧系统软件再工程——仔细分析程序、掌握内部细节，以工程化方式重新组织系统。问题老系统结构混乱系统内部模块耦合严重，层次不清，难以定位与隔离修改影响范围。文档缺失设计文档与维护记录不完整，依赖人工阅读源码理解业务逻辑，成本高。直接修改代价越来越大策对策思路软件再工程：仔细分析程序、掌握内部细节，以工程化方式重新组织系统。定义如何修改老程序以适应新需求。本质系统性偿还技术债务，重新获得可维护、可扩展的代码基础。理解维护是工程能力闭环理解维护、辨析类型、规范过程、保障可维护性，才能让软件的生命真正延续维护不是孤立的修补动作，而是贯穿软件