软件工程软件维护.ppt

软件工程(Software Engineering) 沈阳工业大学信息科学与工程学院 魏东 Slide * 第九章 软件维护 9.1 软件维护基础 定义 软件维护是在软件交付使用之后，为了改正错误或满足新的需求而修改软件的过程。 这个概念中两个重要的关键词：一个是“修改”，维护就是修改软件；另一个是“过程”，过程暗喻不是单一的活动，是活动的集合和活动的有序组合，过程就需要管理。 意义 软件维护是软件生命周期的最后一个阶段。通过软件维护达到的目标是：使软件更好用、功能更强大、寿命更长远。对软件不实施维护就相当放弃软件的生存支持。 软件维护是软件生命周期中时间最长、费用最高、越来越难的活动。 软件维护技术不像开发技术那样成熟和规范，消耗的工作量比较多，其工作量占整个生存周期的70%以上。 9.2软件维护的类型 软件维护的类型 维护类别的意义：一方面用于决策层的维护决策；另一方面可划分责任界限。 软件维护主要三类是： 纠错性维护（Corrective Maintenance）、 适应性维护（Adaptive Maintenance ）、 改善性维护（Perfective Maintenance ） 预防性维护。 纠错性维护：是在软件交付后，纠正哪些在运行中发现的残留错误，也称改正性维护 。 适应性维护：为适应软件运行环境（软件生态环境）的变化而修改软件的活动 。 改善性维护：根据用户在软件使用过程中提出的建设性意见（需求变化）而进行的维护活动。 纠错性维护对开发方是无条件的维护。适应性和改善性维护需要供需双方协商解决 9.2软件维护的类型 大部分维护工作是改变和加强软件，而不是纠错。改正性维护占全部维护量的比率已从80年代初的20%大幅度下降, 90年代初一些公司的产品差错率已接近于零。 其它维护5 % 适应性 维 护 25% 改正性维 护20% 扩充与完 善性维护 50% 9.3 软件可维护性 软件维护的困难 维护的副作用就是指由于维护或在维护过程中其他一些不期望的行为引入的错误。 引起副作用的维护修改可分三类：代码副作用；数据副作用；文档副作用。 维护的困难 1）现场维护人员的压力很大。 2）维护人员不知所措，不知怎样进行修改。 3）维护人员理解别人的程序非常困难。 4）由于维护阶段持续时间很长，造成了维护的困难。 5）维护人员更为困惑的是，有的软件的错误不是程序本身的问题，可能是分析和设计的缺陷。 9.3 软件可维护性 理解代码功能 理解 ？ 修改代码 测试复审 理解设计 方案规划 修改设计 修改代码 测试复审 交付使用 开始 开始 交付使用 结构化维护与非结构化维护的区别 9.3 软件可维护性 非结构维护的问题 具有如下特点的维护属于非结构化维护： 软件的配置中只有源代码。 由于没有分析和设计文档，无法对程序的功能进行反向追踪，理解别人的代码是很痛苦的事情。 由于配置中没有测试文档，所以维护后的代码无法进行回归测试。因而导致程序的结构化被不断的破坏，维护的质量无法得到保证。 9.3 软件可维护性 结构化维护是真正的维护 结构化维护具有下列特点： 待维护的软件的配置是完整的。 用户提出的维护申请用正向追踪很容易从分析设计文档追踪直至代码中，从而使维护人员很容易定位代码的维护点。所以这种维护不会破坏软件的结构。 结构化维护不仅能减少维护的工作量，还能提高维护的质量。 9.4 软件维护的实施 维护的组织与流程 维护组织内的角色一般由维护员，维护管理员，系统管理员，决策机构，配置管理员组成。 系统管理员 维护管理员 维护员 配置管理员 维护申请单 维护决策机构 组织内角色间协调关系图 9.4 软件维护的实施 实施过程 ①用户的维护请求； ②将请求交给系统管理员； ③并提交给决策机构进行； ④通知配置管理员进行配置登记； ⑤组织维护员执行该次维护； ⑥提交维护结果及审核报告； 9.4 软件维护的实施 维护实施的工作内容 用户的维护请求激发了一次维护活动，用户将维护申请提交给维护管理员； 维护管理员将该维护请求交给系统管理员对维护活动可能引起的软件修改进行评估，并将评估结果反馈给维护管理员； 维护管理员按照维护请求单制定软件修改报告单并提交给修改决策机构进行维护决策。修改决策机构根据情况决定采取的行动（拒绝请求还是接收请求），并把结果反馈给维护管理员； 如果允许维护，维护管理员将通知维护员执行该次维护，同时通知配置管理员准备相关文档。 维护管理员将通知并组织维护员执行该次维护； 维护的内容要从配置管理员处获取并提交维护结果，一次维护过程结束要提交审核报告。 9.4