第8章维护导论.ppt

第8章 维护 8.1 软件维护的定义 8.2 软件维护的特点 8.3 软件维护过程 8.4 软件的可维护性 8.5 预防性维护 8.6 软件再工程过程 在软件产品被开发出来并交付用户使用之后，就进入了软件的运行维护阶段。其基本任务是保证软件在一个相当长的时期能够正常运行。 软件维护需要的工作量很大，平均说来，大型软件的维护成本高达开发成本的4倍左右。 8.1 软件维护的定义 所谓软件维护就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。 可分为4项活动： 改正性维护 适应性维护 完善性维护 预防性维护 改正性维护： 把诊断和改正错误的过程称为改正性维护。 改正性维护占17%～21%。 适应性维护： 为了和变化了的环境适当地配合而进行的修改软件的活动，是既必要又经常的维护活动。 包括外部环境和数据环境的变化。 适应性维护占18%～25%。 完善性维护： 为了满足在用户提出的增加新功能或修改已有功能的要求和一般性的改进要求，需要进行完善性维护。 包括功能和性能的要求。 完善性维护占50%～66%。 预防性维护： “把今天的方法学应用于昨天的系统以满足明天的需要。” 采用先进的软件工程方法对需要维护的软件或软件中的某一部分，主动地进行重新设计、编码和测试。 预防性维护占4%左右。 只有预防性维护是主动的，其他维护都是被动的。 影响维护工作量的主要因素： 系统规模 开发工具和平台 系统年龄 数据库技术的应用 先进的软件开发技术 许多软件在开发时并未考虑将来的修改，为软件的维护带来许多问题，是影响软件维护工作量的最主要因素。 8.2 软件维护的特点8.2.1 结构化维护与非结构化维护差别巨大 1. 非结构化维护 如果软件配置的惟一成分是程序代码，那么维护活动从艰苦地评价程序代码开始，而且常常由于程序内部文档不足而使评价更困难。 非结构化维护需要付出很大代价，这种维护方式是没有使用良好定义的方法学开发出来的软件的必然结果。 2. 结构化维护 如果有一个完整的软件配置存在，那么维护工作从评价设计文档开始，确定软件重要的结构特点、性能特点以及接口特点；估量要求的改动将带来的影响，并且计划实施途径。 然后首先修改设计并且对所做的修改进行仔细复查。接下来编写相应的源程序代码；使用在测试说明书中包含的信息进行回归测试； 最后，把修改后的软件再次交付使用。 8.2.2 维护的代价高昂 在过去的几十年中，软件维护的费用稳步上升。 1970年用于维护已有软件的费用只占软件总预算的35%～40%； 1980年上升为40%～60%； 1990年上升为70%～80%。 8.2.3 维护的问题很多 维护的问题： 理解别人写的程序通常非常困难，而且困难程度随着软件配置成分的减少而迅速增加。 需要维护的软件往往没有合格的文档，或者文档资料显著不足。 当要求对软件进行维护时，不能指望由开发人员给我们仔细说明软件。 绝大多数软件在设计时没有考虑将来的修改。 软件维护不是一项吸引人的工作。 8.3 软件维护过程 维护组织 维护管理员将每个维护要求转交给相应的系统管理员去评价，然后由变化授权人决定应该进行的活动。 维护报告 用户填写“维护要求表”（软件问题报告） 系统管理员书写“软件修改报告”，提交给变化授权人审查 维护的事件流 首先，确定要求进行的维护的类型 改正性维护，从估量错误的严重程度开始 适应性或完善性维护，先确定维护要求的优先次序 之后，修改软件设计、复查、修改程序代码、测试、复审 保存维护记录 评价维护活动 8.4 软件的可维护性 可定义为： 维护人员理解、改正、改动或改进这个软件的难易程度。 提高可维护性是支配软件工程方法学所有步骤的关键目标。 8.4.1 决定软件可维护性的因素 决定软件可维护性的因素主要有7个： 可理解性 可测试性 可修改性 可靠性 可移植性 可使用性 效率 1. 可理解性 软件可理解性表现为外来读者理解软件的结构、功能、接口和内部处理过程的难易程度。 模块化（模块结构良好，高内聚，松耦合）、详细的设计文档、结构化设计、程序内部的文档和良好的高级程序设计语言等等，都对提高软件的可理解性有重要贡献。 2. 可测试性 可测试性表明论证程序正确性的容易程度。 程序越简单，证明其正确性就越容易。 对于程序模块来说，可以用程序复杂度来度量它的可测试性。模块的环形复杂度越大，可执行的路径就越多，因此，全面测试它的难度就越高。 3. 可修改性 可修改性表明程序容易修改的程度。 一个可修改的程序应当是可理解的、通用的、灵活的、简单的 4. 可靠性 可靠性表明一个程序按照用户的要求和设计目标，在给定的一段时间内正确执行的概率。 度量的标准主要有：平均无故