12软件维护基础.pptVIP

2021/2/12 * 程序是否能始终如一地按照用户的要求运行? 程序是否让用户对数据处理有一个满意的和适当的控制? 程序是否容易学会使用? 程序是否使用数据管理系统来自动地处理事务性工作和管理格式化、地址分配及存储器组织。 程序是否具有容错性? 程序是否灵活? 2021/2/12 * 其它间接定量度量可维护性的方法 问题识别的时间; 因管理活动拖延的时间; 收集维护工具的时间; 分析、诊断问题的时间; 修改规格说明的时间; 具体的改错或修改的时间; 局部测试的时间; 集成或回归测试的时间; 维护的评审时间; 2021/2/12 * 这些数据反映了维护全过程中检错－纠错－验证的周期,即从检测出软件存在的问题开始至修正它们并经回归测试验证这段时间。 可以粗略地认为,这个周期越短,维护越容易。 2021/2/12 * 提高可维护性的方法 建立明确的软件质量目标和优先级 使用提高软件质量的技术和工具 进行明确的质量保证审查 选择可维护的程序设计语言 改进程序的文档 2021/2/12 * 软件维护工作流程 2021/2/12 * 尽管维护申请的类型不同,但都要进行同样的技术工作。 修改软件需求说明 修改软件设计 设计评审 对源程序做必要的修改 单元测试 集成测试( 回归测试) 确认测试 软件配置评审等。 2021/2/12 * 在每次软件维护任务完成后进行情况评审,对以下问题做一总结:(1) 在目前情况下,设计、编码、测试中的哪一方面可以改进?(2) 哪些维护资源应该有但没有?(3) 工作中主要的或次要的障碍是什么?(4) 从维护申请的类型来看是否应当有预防性维护?情况评审对将来的维护工作如何进行会产生重要的影响。 2021/2/12 * 维护档案记录 程序名称 源程序语句条数 机器代码指令条数 所用的程序设计语言 程序安装的日期 程序安装后的运行次数 与程序安装后运行次数有关的处理故障次数 2021/2/12 *  程序改变的层次及名称 修改程序增加的源程序语句条数 修改程序减少的源程序语句条数 每次修改所付出的“人时”数 修改程序的日期 软件维护人员的姓名 维护申请报告的名称、维护类型 维护开始时间和维护结束时间、 花费在维护上的累计“人时”数 维护工作的净收益等。 2021/2/12 * 维护评价 评价维护活动比较困难,因为缺乏可靠的数据。 如果维护的档案记录做得比较好,可以得出一些维护“性能”方面的度量值。 每次程序运行时的平均出错次数; 花费在每类维护上的总“人时”数; 2021/2/12 * 每个程序、每种语言、每种维护类型的程序平均修改次数; 因为维护,增加或删除每个源程序语句所花费的平均“人时”数; 用于每种语言的平均“人时”数; 维护申请报告的平均处理时间; 各类维护申请的百分比。 据此可对开发技术、语言选择、维护工作计划、资源分配、以及其它许多方面做出判定。 2021/2/12 * 程序修改的步骤及修改的副作用 分析和理解程序 修改程序 重新验证程序 2021/2/12 * 分析和理解程序 理解程序的功能和目标; 掌握程序的结构信息,即从程序中细分出若干结构成分。如程序系统结构、 控制结构、数据结构和输入／输出结构等; 了解数据流信息,即涉及到的数据来源何处,在哪里被使用 了解控制流信息,即执行每条路径的结果; 理解程序的操作(使用)要求; 2021/2/12 * 修改程序 1. 设计程序的修改计划 程序的修改计划要考虑人员和资源的安排。小的修改可以不需要详细的计划,而对于需要耗时数月的修改,就需要计划立案。 2. 修改代码,以适应变化 3. 修改程序的副作用 所谓副作用是指因修改软件而造成的错误或其它不希望发生的情况。副作用有三种:修改代码的副作用、修改数据的副作用、文档的副作用。 2021/2/12 * 重新验证程序 在将修改后的程序提交用户之前,需要进行充分的确认和测试,以保证整个修改后程序的正确性。 静态确认修改软件,伴随着引起新的错误的危险。为了能够做出正确的判断,验证修改后的程序至少需要两个人参加。要检查: 2021/2/12 * 计算机确认在进行了以上确认的基础上,用计算机对修改程序进行确认测试:(1) 确认测试顺序:先对修改部分进行测试,然后隔离修改部分,测试程序的未修改部分,最后再把它们集成起来进行测试。这种测试称为回归测试。 (2) 准备标准的测试用例。(3) 充分利用软件工具帮助重新验证过程。 2021/2/12 * (4) 在重新确认过程中,需邀请用户参加。 维护后的验收──在交付新软件之前,维护主管部门要检验:(1) 全部文档是否完备,并已更新;(2) 所有测试用例和测试结果已经正确记载;(3) 记