第九章-软件维护课件.pptVIP

尽管维护申请的类型不同，但都要进行同样的技术工作。 修改软件需求说明 修改软件设计 设计评审 对源程序做必要的修改 单元测试 集成测试( 回归测试) 确认测试 软件配置评审等。 在每次软件维护任务完成后进行情况评审，对以下问题做一总结：(1) 在目前情况下，设计、编码、测试中的哪一方面可以改进?(2) 哪些维护资源应该有但没有?(3) 工作中主要的或次要的障碍是什么?(4) 从维护申请的类型来看是否应当有预防性维护?情况评审对将来的维护工作如何进行会产生重要的影响。 维护档案记录 程序名称 源程序语句条数 机器代码指令条数 所用的程序设计语言 程序安装的日期 程序安装后的运行次数 与程序安装后运行次数有关的处理故障次数  程序改变的层次及名称 修改程序增加的源程序语句条数 修改程序减少的源程序语句条数 每次修改所付出的“人时”数 修改程序的日期 软件维护人员的姓名 维护申请报告的名称、维护类型 维护开始时间和维护结束时间、 花费在维护上的累计“人时”数 维护工作的净收益等。 维护评价 评价维护活动比较困难，因为缺乏可靠的数据。 如果维护的档案记录做得比较好，可以得出一些维护“性能”方面的度量值。 每次程序运行时的平均出错次数； 花费在每类维护上的总“人时”数； 每个程序、每种语言、每种维护类型的程序平均修改次数； 因为维护，增加或删除每个源程序语句所花费的平均“人时”数； 用于每种语言的平均“人时”数； 维护申请报告的平均处理时间； 各类维护申请的百分比。 据此可对开发技术、语言选择、维护工作计划、资源分配、以及其它许多方面做出判定。 程序修改的步骤及修改的副作用 分析和理解程序 修改程序 重新验证程序 分析和理解程序 理解程序的功能和目标； 掌握程序的结构信息，即从程序中细分出若干结构成分。如程序系统结构、 控制结构、数据结构和输入／输出结构等； 了解数据流信息，即涉及到的数据来源何处，在哪里被使用 了解控制流信息，即执行每条路径的结果； 理解程序的操作(使用)要求； 修改程序 1. 设计程序的修改计划 程序的修改计划要考虑人员和资源的安排。小的修改可以不需要详细的计划，而对于需要耗时数月的修改，就需要计划立案。 2. 修改代码，以适应变化 3. 修改程序的副作用 所谓副作用是指因修改软件而造成的错误或其它不希望发生的情况。副作用有三种：修改代码的副作用、修改数据的副作用、文档的副作用。 重新验证程序 在将修改后的程序提交用户之前，需要进行充分的确认和测试，以保证整个修改后程序的正确性。 静态确认修改软件，伴随着引起新的错误的危险。为了能够做出正确的判断，验证修改后的程序至少需要两个人参加。要检查： 计算机确认在进行了以上确认的基础上，用计算机对修改程序进行确认测试：(1) 确认测试顺序：先对修改部分进行测试，然后隔离修改部分，测试程序的未修改部分，最后再把它们集成起来进行测试。这种测试称为回归测试。 (2) 准备标准的测试用例。(3) 充分利用软件工具帮助重新验证过程。 (4) 在重新确认过程中，需邀请用户参加。 维护后的验收──在交付新软件之前，维护主管部门要检验：(1) 全部文档是否完备，并已更新；(2) 所有测试用例和测试结果已经正确记载；(3) 记录软件配置所有副本的工作已经完成；(4) 维护工序和责任已经确定。 软件可维护性的定义 软件可维护性是指纠正软件系统出现的错误和缺陷，以及为满足新的要求进行修改、扩充或压缩的容易程度。 可维护性、可使用性、可靠性是衡量软件质量的主要质量特性。 软件的可维护性是软件开发阶段各个时期的关键目标。 软件可维护性 目前广泛使用的是用如下的七个特性来衡量程序的可维护性。 可理解性 可使用性 可测试性 可移植性 可修改性 效率 可靠性 而且对于不同类型的维护，这七种特性的侧重点也不相同。 在各类维护中的侧重点 可维护性的度量 人们一直期望对软件的可维护性做出定量度量，但要做到这一点并不容易。 常用的度量一个可维护的程序的七种特性的方法。就是 质量检查表 质量测试 质量标准 。。 * 。。 * 第九章 软件维护 软件维护的概念 软件维护活动 程序修改的步骤及修改的 副作用 软件可维护性 提高可维护性的方法 软件维护的概念 软件维护的定义 影响维护工作量的因素 软件维护的策略 维护成本 软件维护的定义 在软件运行／维护阶段对软件产品进行的修改就是所谓的维护。 维护的类型有四种： 改正性维护 适应性维护 完善性维护 预防性维护 改正性维护 在软件交付使用后，因开发时测试的不彻底、不完全，必然会有部分隐藏的错误遗留到运行阶段。 这些隐藏下来的错误在某些特