车海燕-软件工程-Lecture-SE-2013-Chap08.pptVIP

软件工程 - 2013 - 第八章 软件维护 第八章软件维护 软件维护：就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。 维护的类型： 改正性维护（Corrective maintenance） 适应性维护（Adaptive maintenance） 完善性维护（Perfective maintenance） 预防性维护（Preventive maintenance） 结构化维护与非结构化维护差别巨大 维护的代价高昂 维护的问题很多 结构化维护： 有完整的软件配置，能够提高维护的整体质量。 非结构化维护： 缺少相关文档使得维护的代价巨大。 有形的维护代价：费用。 无形的维护代价有更大的影响： 贻误良机； 一些合理的修复或修改请求不能及时安排，使得客户不满意； 变更的结果引入新的故障，使得软件整体质量下降； 把软件人员抽调到维护工作中，干扰了软件开发工作。 生产率大幅下降。 软件维护工作量 生产性活动：如分析和评价、设计修改和实现 非生产性活动：如力图理解代码功能、解释数据结构、接口特性、性能限度等。 维护工作量的模型： 与软件维护有关的绝大多数问题，都可归因于软件定义和软件开发的方法有缺点： 理解别人写的程序通常非常困难，而且困难程度随着软件配置成分的减少而迅速增加。 需要维护的软件往往没有合格的文档，或者文档资料显著不足。 当要求对软件进行维护时，不能指望由开发人员给我们仔细说明软件。 绝大多数软件在设计时没有考虑将来的修改。 软件维护不是一项吸引人的工作。 为了有效地进行软件维护，应事先就开始做组织工作： 首先建立维护组织； 确定提出维护申请报告的过程及评价的过程； 为每一个维护申请规定标准化的事件序列； 建立适用于维护活动的记录保管过程以及规定复审标准。 维护要求表或称软件问题报告表，由申请维护的用户填写。 软件修改报告，由软件组织内部制定，要指明： 满足某个维护要求表中提出的要求所需要的工作量； 维护要求的性质； 这项要求的优先级； 与修改有关的事后数据； 尽管维护申请的类型不同，但都要进行同样的技术工作： 修改软件设计 复查设计 对源程序做必要的修改 单元测试 集成测试（回归测试） 确认测试 复审 程序名称 源程序语句条数 机器代码指令条数 所用的程序设计语言 程序安装的日期 程序安装后的运行次数 程序安装后程序失效的次数 程序改变的层次及名称 修改程序增加的源程序语句条数 修改程序减少的源程序语句条数 每次修改所付出的“人时”数 修改程序的日期 软件维护人员的姓名 维护要求表的名称 维护类型 维护开始时间和维护结束时间、 花费在维护上的累计“人时”数 维护工作的净收益等 每次程序运行时的平均失效次数； 花费在每类维护上的总“人时”数； 每个程序、每种语言、每种维护类型的程序平均修改次数； 因为维护，增加或删除每个源程序语句所花费的平均“人时”数； 用于每种语言的平均“人时”数； 一张维护要求表的平均周转时间； 不同维护类型所占的百分比。 软件的可维护性：维护人员理解、改正、改动或改进这个软件的难易程度。 决定软件可维护性的因素： 可理解性 可测试性 可修改性 可移植性 可重用性 用户文档 系统文档 各类文档必须如实反映软件的当前状态。 在需求分析阶段的复审过程中，应该对将来要改进的部分和可能会修改的部分加以注意并指明；应该讨论软件的可移植性问题，并且考虑可能影响软件维护的系统界面。 在正式的和非正式的设计复审期间，应该从容易修改、模块化和功能独立的目标出发，评价软件的结构和过程；设计中应该对将来可能修改的部分预做准备。 代码复审应该强调编码风格和内部说明文档这两个影响可维护性的因素。 在测试结束时进行最正式的可维护性复审，这个复审称为配置复审。配置复审的目的是保证软件配置的所有成分是完整的、一致的和可理解的，而且为了便于修改和管理已经编目归档了。 在完成了每项维护工作之后，都应该对软件维护本身进行仔细认真的复审。 Legacy System 预防性维护方法是由Miller提出来的，他把这种方法定义为：“把今天的方法学应用到昨天的系统上，以支持明天的需求。” 为了修改这类程序以适应用户新的或变更的需求，有以下几种做法可供选择： （1） 反复多次地做修改程序的尝试，与不可见的设计及源代码“顽强战斗”，以实现所要求的修改； （2） 通过仔细分析程序尽可能多地掌握程序的内部工作细节，以便更有效地修改它； （3） 在深入理解原有设计的基础上，用软件工程方法重新设计、重新编码和测试那些需要变更的软件部分； （4） 以软件工程方法学为指导，对程序全部重新设计、重新编码和测试，为此可以使用CASE工具（逆向工程和再工程工具）来帮助理解原有的设计。 在一个正在工作的程序版本已经存在的情