SE-第12章-软件维护解读.pptVIP

软件工程Software Engineering 计算机学院 软件工程课程组 思考? 软件要不要维护？ 软件维护的内容包括哪些方面？ 软件生存期 第12章 软件维护 软件维护的类型有哪些？ 如何提高软件的可维护性？ 一、软件维护的类型 校正性维护/纠错性维护（corrective maintenace） 适应性维护（adaptive maintenance） 完善性维护（perfective maintenance） 预防性维护（preventive maintenace） 二、软件维护的特点 软件工程方法对维护的影响 结构化方法：SA／SD 面向对象：OOM 规范文档、良结构、单元独立性、可跟踪性 维护的代价 表面上看来合理的改错或修改不能完全满足用户的要求，就会引起用户的不满。 由于维护时对软件的改动，哪怕是很小的改动，在软件中也会引入潜在的隐患或错误，使得整个软件的质量降低， 特别是不可再现错误。 在开发工作期间，由于工作需要必须把软件工程师调去从事维护工作，就会对开发工作造成不良影响。 软件维护会使生产率大幅度下降 维护中的问题 阅读和理解问题 人员问题 文档资料 软件的修改 软件维护相对于软件系统开发工作来说则毫无吸引力 可维护性 可维护性的决定因素 可理解性 可测试性 (1) 计测性 (2) 存取性 (3) 通信性 (4) 自身描述性 (5) 结构性 可修改性 可维护性的定性度量 1)识别问题的时间； (2)管理的延迟时间; (3)维护工具的收集时间; (4)分析和诊断问题 的时间 (5)修改规范说明的时间；(6)实际校正(或修改)的时间； (7)局部测试时间； (8)整体测试时间 (9)复审时间； (10)总的恢复时间 二、提高可维护性的措施 需求分析 清晰、易读、结构好 → 易修改 设计 结构层次清晰、独立性强 → 修改局部化 灵活的数据逻辑结构 → 适应处理的变化 编码 编码规则、风格 SP 通用性高的PL 测试 测试充分 文档 三、维护机构 提出维护申请和评估 维护申请是由软件组织外部提交的文档，它是计划 维护活动的基础。它由维护管理员和系统监督员来研 究处理并依此制定相应的软件修改报告(MCR)，这个 报告包括以下内容： （1）所需修改变动的性质； （2）申请修改的优先级； （3）为满足某个维护申请要求所需的工作量； （4）与修改有关的事后数据，预计修改后的状况。 MCR应提交修改负责人，经审核批准后，开始安排 下一步工作。 尽管维护申请的类型不同，但都要进行同样的技术工作。 修改软件需求说明 修改软件设计 设计评审 对源程序做必要的修改 单元测试 集成测试( 回归测试) 确认测试 软件配置评审等。 四、维护的副作用 修改软件后导致新错误的发生 编码的副作用 数据的副作用 文档资料的副作用 代码副作用 1.删除或修改子程序； 2.删除或修改语句标号； 3.删除或修改标识符； 4.为改进性能所作的修改； 5.修改文件的打开和关闭语句； 6.修改逻辑运算符； 7.由设计变动引起的代码修改； 8.对边界测试所作的修改。 为确保编码修改没有引入新的错误，应进行严格 的回归测试。一般情况下，通过回归测试，可以发 现并纠正修改编码所带来的副作用。 数据副作用 重新定义局部常量或全局常量； 重新定义记录格式或文件格式； 增加或减少数组和高阶数据结构的大小； 修改全局和公共数据； 重新初始化控制标志或指针； 重新安排I/O表或子程序的参数表。 完善的设计文档资料可以减少数据的副作用。利 用文档资料对数据及其用途所作的详细描述 ，提供 了数据项、记录、文件及其他结构与软件模块间相 关的参照表，是维护期间对数据结构进行修改的主 要依据。 文档副作用 在维护过程中，如果源程序修改了，而相应 的资料或用户手册未作相应的修改，则会产生 文档资料的副作用。因为维护应该针对整个软 件配置，不应该只修改源程序。 在软件再次交付使用之前，对整个软件配置 进行评审将大大减少文档的副作用。实际上， 某些维护申请的提出只是由于用户文档不够清 楚。这时，只需对文档进行维护即可，并不要 求修改软件设计或源程序。 小 结 软件维护的类型 提高可维护性的措施 维护机构 维护的副作用 用于软件维护的工作量可以分为两部分：一部 分用于生产性活动，另一部分用于非生产性活动。 由Belady和Lehman提出的维护工作量的计算模