软件工程学软件维护研讨.pptVIP

* * 维护申请提交给维护管理员，他把申请交给某个系统监督员去评价。 一旦做出评价，由修改负责人确定如何进行修改。 在修改程序的过程中，由配置管理员严格把关，控制修改的范围，对软件配置进行审计。 在维护之前，就把责任明确下来，可以减少维护过程中的混乱。 维护组织 * * 4.2 维护报告和评估 维护申请报告 完成维护任务的主要依据。 或称软件问题报告，由申请维护的用户填写。 应以标准化的形式 纠正性维护：记录出错现场(输入数据、出错信息等) 适应性和完善性维护：提供简短的修改规格说明书 * *  软件修改报告 维护申请报告将由维护管理员和系统监督员来研究处理； 他们做出软件修改报告，指明： 所需修改变动的性质； 申请修改的优先级； 为满足某个维护申请报告，所需的工作量； 预计修改后的状况. 软件修改报告应提交修改负责人，经批准后才能开始进一步安排维护工作。 4.2 维护报告和评估 * * 4.3 维护活动事件流 （1）确认用户的维护请求 （2）按关键程度将每一维护任务在维护任务队列中排队 （3）对队首的维护任务开展工作 （4） 状况复审 * * 软件维护工作流程 * * 尽管维护申请的类型不同，但都要进行同样的技术工作。 修改软件需求说明 修改软件设计 设计评审 对源程序做必要的修改 单元测试 集成测试( 回归测试) 确认测试 软件配置评审等。 4.3 维护活动事件流 * * 状况复审 在每次软件维护任务完成后进行情况评审，对以下问题做一总结 (1) 在目前情况下，设计、编码、测试中的哪一方面可以改进? (2) 哪些维护资源应该有但没有? (3) 工作中主要的或次要的障碍是什么? (4) 从维护申请的类型来看是否应当有预防性维护? 情况评审对将来的维护工作如何进行会产生重要的影响。 * * 4.4 保存维护纪录 记录维护活动过程中的各种信息。目的： 估算维护技术的有效性 估算维护技术的实际成本 * * 维护档案记录 程序名称 源程序语句条数 机器代码指令条数 所用的程序设计语言 程序安装的日期 程序安装后的运行次数 与程序安装后运行次数有关的处理故障次数 程序改变的层次及名称 * *  修改程序增加的源程序语句条数 修改程序减少的源程序语句条数 每次修改所付出的“人时”数 修改程序的日期 软件维护人员的姓名 维护申请报告的名称、维护类型 维护开始时间和维护结束时间、 花费在维护上的累计“人时”数 维护工作的净收益等。 维护档案记录(续) * * 4.5 维护评价 评价维护活动比较困难，因为缺乏可靠的数据。 如果维护的档案记录做得比较好，可以得出一些维护“性能”方面的度量值。 每次程序运行时的平均出错次数； 花费在每类维护上的总“人时”数； 每个程序、每种语言、每种维护类型的程序平均修改次数； * * 维护评价（续） 因为维护，增加或删除每个源程序语句所花费的平均“人时”数； 用于每种语言的平均“人时”数； 维护申请报告的平均处理时间； 各类维护申请的百分比。 * * 5 维护的副作用 由于维护或者在维护过程中其他一些不期望的行为引入的错误。 代码副作用 数据副作用 文档副作用 * *  在修改源代码时可能引入错误。如： 删除或修改一个子程序; 删除或修改一个标号; 删除或修改一个标识符; 改变程序代码的时序关系; 改变占用存储的大小; 改变逻辑运算符; 修改文件的打开或关闭; 改进程序的执行效率; 把设计上的改变翻译成代码的改变。 (1) 修改代码的副作用 * * (2) 修改数据的副作用 在修改数据结构时，有可能造成软件设计与数据结构不匹配，因而导致软件出错。 数据副作用就是修改软件信息结构导致的结果。 * * 容易导致设计与数据不相容的错误： 重新定义局部的或全局的常量 重新定义记录或文件的格式 增大或减小一个数组或高层数据结构的大小 修改全局或公共数据 重新初始化控制标志或指针 重新排列输入／输出或子程序的参数 (2) 修改数据的副作用 * * (2) 修改数据的副作用 数据副作用可以通过交叉引用表加以控制。把数据元素、记录、文件和其它结构联系起来。 * * (3) 文档的副作用 对数据流、软件结构、模块逻辑或任何其它有关特性进行修改时，必须对相关技术文档进行相应修改。 否则会导致文档与程序功能不匹配，缺省条件改变，新错误信息不正确等错误。使得软件文档不能反映软件的当前状态。 * * 如果对可执行软件的修改不反映在文档里，就会产生文档的副作用。 对交互输入的顺序或格式进行修改，如果没有正确地记入文档中，就可能引起重大的问题。 过时的文档内容、索引和文本可能造成冲突，引起用户失败和不满。 因此，必须在软件交付之前对整个软件配置进行评审，以减少文档的副