软件工程-6.ppt

软件工程 软件工程 第五章 软件测试 第六章 软件维护 6.1软件维护的定义 6.2软件维护的特点 6.3软件维护过程 6.4软件可维护性 6.5软件维护的副作用 6.1 软件维护的定义 * 软件工程 1. 软件维护的定义 在软件产品被开发出来并交付使用之后，就进入了软件的运行维护阶段。 软件维护的工作量很大，平均来说，大型软件的维护成本高达开发成本的4倍，目前，国外许多软件开发组织把60%以上的人力用于维护已有的软件。 软件维护就是在软件已经交付使用之后，为了改正错误或满足新的需要修改软件的过程。 2. 软件维护的原因 软件测试不可能暴露出一个大型软件系统中所有潜藏的错误。 一般来说，进行软件维护的原因有如下几种 改正程序中的错误和缺陷； 改进设计以适应新的软、硬件环境； 增加新的应用范围； 3. 软件维护的种类 改正性维护（Corrective maintenance），在任何大型程序的使用期间，用户必然会发现程序错误，并且把他们遇到的问题报告给维护人员，把诊断和改正错误的过程称为改正性维护。 适应性维护（Adaptive maintenance） ，为了和变化了的环境适当地配合而进行的修改软件的活动。它是既必要又经常进行的维护活动。 完善性维护（Perfective maintenance） ，在使用软件的过程中用户往往提出增加新功能或修改已有功能的建议，还可能提出一般性的改进意见。为了满足这类用户要求，需要进行完善性维护。这项维护活动通常占软件维护工作的大部分。 预防性维护（Preventive maintenance） ，当为了改进未来的可维护性或可靠性，或为了给未来的改进奠定更好的基础而修改软件时，这类维护活动称为预防性维护。目前这类维护活动相对比较少。 4. 影响维护工作量的因素 系统的规模,系统越大，理解掌握起来越困难。系统越大，所执行功能越复杂。 系统的年龄，老系统随着不断的修改，结构越来越混乱，由于维护人员经常更换，程序又变得越来越难于理解。 系统的结构，系统越是模块化，就越容易进行体系结构的变更。 程序设计语言，使用强功能的程序设计语言可以控制程序的规模。有许多软件是用老的程序设计语言书写的，程序逻辑复杂而混乱，且没有做到模块化和结构化，直接影响到程序的可读性。 先进的软件开发技术，在软件开发时，若使用能使软件结构比较稳定的分析与设计技术，用程序设计技术，如面向对象技术，复用技术等，可减少大量的工作量。 6.2 软件维护的特点 1. 软件工程与维护的关系 结构化维护，维护工作从评价设计文档开始，首先修改设计并且对所做的修改进行仔细复查，接下来编写相应的源程序代码，最后把修改后的软件再次交付使用。 非结构化维护，维护活动从艰苦的评价程序代码开始，而且常常由于程序内部文档不足而使评价更困难。 配置 评价设计 计划途径 修改设计 重新编码 评价代码 ？ 复查 重新编码 复查 维护要求 交付使用 软件 代码 结构化维护 非结构化维护 2. 维护成本 有形的维护成本，维护过程花费了多少钱。 无形的维护成本，它对于维护成本有更大的影响。无形的成本包括： 一些看起来是合理的改错或修改的要求不能及时满足，使得用户不满意； 维护时产生的改动，可能会带来新的潜伏的故障，从而降低了软件的整体质量； 当必须把软件开发人员抽调去进行维护工作时，就使得软件开发工作受到干扰； 6.3 软件维护过程 1. 软件维护机构 除了较大机构外，通常在软件维护工作方面，并不保持一个正式的组织机构，维护往往是没有计划的情况下进行的。 维护管理员负责接受维护申请，然后把维护申请交给某个系统监督员去评价。系统管理员是一名技术人员，他必须熟悉软件产品的某一部分。系统监督员对维护申请做出评价，然后交与修改负责人确定如何进行修改。在维护人员对程序进行修改的过程中，由配置管理员严格把关，控制修改的范围，对软件配置进行审计。 系统监督员 维护要求 维护管理员 修改负责人 维护人员 配置管理员 软件维护机构 在开始维护之前，就把责任明确下来，可以大大减不维护过程中的混乱。 2. 维护申请报告 应当用标准化的格式表达所有软件维护的要求。 软件组织内部应该制定出一个软件修改报告，它给出如下信息： 为满足某个维护申请要求所需的工作量； 所需修改变动的性质； 申请修改的优先级； 与修改有关的事后数据。 3. 维护的工作流程 评价错误 严重程度 改正性 确定类型 维护要求 评价 优先次序 完善性 或适应性 开始 问题分析 严重 不严重 安排改正 性维护 错误改正目录 开始分析 维护任务 复审 开发目录 低 高 人员安排 修改后的软件 通过后交付使用的软件 人员安排 ① 无论是哪一种类型的维护，都要进行以下工作： 修改软件设计； 设计复审； 对