Chapter8维护-1学时.pptVIP

第8章 维护 8.1 软件维护的定义 8.2 软件维护的特点 8.3 软件维护过程 8.4 软件的可维护性 8.5 预防性维护 8.6 软件再工程过程 8.1 软件维护的定义 软件工程的目的： 提高软件的可维护性； 减少软件维护所需要的工作量； 降低软件系统的总成本。 软件维护定义：指软件系统交付使用以后，为了改正错误或满足新的需求而修改软件的过程。 大型软件维护成本达软件开发成本的4倍左右； 60%以上的人力用于维护已有的软件。 8.2 软件维护的特点 8.2.3 维护的问题很多 影响维护代价的技术和非技术因素 非技术因素： 应用域的复杂性。 开发人员的稳定性。 软件的生命期。 商业操作模式变化对软件的影响。 技术因素： 软件对运行环境的依赖性。 编程语言。 编程风格。 测试与改错工作。 文档的质量。 8.3 软件维护过程 图8.1 维护组织 维护报告 应该用标准化的格式表达所有软件维护要求。软件维护人员通常给用户提供空白的维护要求表——有时称为软件问题报告表，这个表格由要求一项维护活动的用户填写。如果遇到了一个错误，那么必须完整描述导致出现错误的环境(包括输入数据、全部输出数据以及其他有关信息)。对于适应性或完善性的维护要求，应该提出一个简短的需求说明书。如前所述，由维护管理员和系统管理员评价用户提交的维护要求表。 图8.2 维护阶段的事件流 保存维护记录 评价维护活动 度量维护工作的7个方面： (1) 每次程序运行平均失效的次数； (2) 用于每一类维护活动的总人时数； (3) 平均每个程序、每种语言、每种维护类型所做的程序变动数； (4) 维护过程中增加或删除一个源语句平均花费的人时数； (5) 维护每种语言平均花费的人时数； (6) 一张维护要求表的平均周转时间； (7) 不同维护类型所占的百分比。 8.4 软件的可维护性 软件的可维护性定义： 维护人员理解、改正、改动或改进这个软件的难易程度。 决定软件可维护性的因素 可理解性;可测试性;可修改性;可移植性;可重用性 文档 用户文档:功能描述；安装文档；使用手册；参考手册；操作员指南 系统文档:从问题定义、需求说明到验收测试计划一系列和系统实现有关的文档。 可维护性复审 8.5 预防性维护 “把今天的方法学应用到昨天的系统上，以支持明天的需求。” ——Miller对预防性维护的定义 反复多次地修改程序的尝试； 通过仔细分析程序尽可能多掌握程序的内部工作细节，以便更有效地修改它； 在深入理解原有设计的基础上，用软件工程方法重新设计、重新编码和测试那些需要变更的软件部分；——局部再工程 以软件工程方法学为指导，对程序全部重新设计、重新编码和测试，可以使用CASE工具来帮助理解原有的设计。——软件再工程 8.6 软件再工程过程 图8.3 软件再工程过程模型 再生工程主要有三种类型： 重构：重构一般是指通过修改代码或数据以使软件符合新的要求。 逆向工程：逆向工程来源于硬件世界。 前向工程：前向工程也称预防性维护 8.7 本章小结 作业 维护代价高昂 虽然通常并不需要建立正式的维护组织，但是，即使对于一个小的软件开发团体而言，非正式地委托责任也是绝对必要的。每个维护要求都通过维护管理员转交给相应的系统管理员去评价。系统管理员是被指定去熟悉一小部分产品程序的技术人员。系统管理员对维护任务做出评价之后，由变化授权人决定应该进行的活动。图8.1描绘了上述组织方式。 在维护活动开始之前就明确维护责任是十分必要的，这样做可以大大减少维护过程中可能出现的混乱。 3. 维护的事件流 图8.2描绘了由一项维护要求而引出的一串事件。首先应该确定要求进行的维护的类型。用户常常把一项要求看作是为了改正软件的错误(改正性维护)，而开发人员可能把同一项要求看作是适应性或完善性维护。当存在不同意见时必须协商解决。 对于软件生命周期的所有阶段而言，以前记录保存都是不充分的，而软件维护则根本没有记录保存下来。由于这个原因，往往不能估价维护技术的有效性，不能确定一个产品程序的“优良”程度，而且很难确定维护的实际代价是什么。 再生工程主要出于如下愿望： 1.在商业上要提高产品的竞争力； 2.在技术上要提高产品的质量。但这种愿望无法靠软件的维护来实现，因为：（1）软件的可维护性可能极差，实在不值得去做；（2）即使软件的可维护性比较好，但也只是治表不治本。再生工程干脆对已有软件进行全部或部分的改造，赋予软件新的活力。 重构一般是指通过修改代码或数据以使软件符合新的要求。重构通常并不推翻原有软件的体系结构，主要是改造一些模块和数据结构。重构的一些好处如下： 1.使软件的质量更高，或使软件顺应