实用软件工程软件维护.pptVIP

教育科学学院 李新晖 * 第5章软件维护 第5章软件维护 * 本章内容： l 软件维护的种类、过程和副作用 l 软件的可维护性 重点： l 如何提高软件的可维护性 5.1软件维护种类、过程和副作用 * 软件维护（software maintenance） 就是在软件产品交付之后对其进行修改，以排除故障，或改进性能和其它属性，或使产品适应改变了的环境。 5.1.1 维护的种类 * 软件维护活动有如下四类 ： 改正性维护 适应性维护 完善性维护 预防性维护 改正性维护 * 改正在系统开发阶段已发生的而系统测试阶段尚未发现的错误。 一般来说，这类故障由于遇到了以前从未有过的某种输入数据的组合，或者是系统的硬件和软件有了不正确的界面而引起的。 适应性维护 * 为适应软件的外界环境变化而进行的修改。 完善性维护 为扩充系统的功能和改善系统性能而进行的修改。 预防性维护 为减少或避免以后可能需要的前三类维护而对软件配置进行的工作。 5.1.2 维护的特点结构性维护与非结构性维护 * 软件维护的成本 * 20世纪70年代，一个信息系统机构用于软件维护的费用占其软件总预算的35%~40%. 80年代接近60%。 若维护方式没有大的改进，未来几年，许多大型软件公司可能要将其预算的80%用于软件系统的维护上。 软件维护的困难 * 很难甚至不可能追踪软件版本的进化过程，软件的变化没在相应文档中反映出来。 很难甚至不可能追踪软件的整个创建过程。 理解他人的程序非常困难，当软件配置不全，仅有源代码时问题尤为严重。 软件人员流动性很大，维护他人软件时很难得到开发者的帮助。 软件没有文档、或文档不全、或文档不易理解、或与源代码不一致。 多数软件设计未考虑修改的需要（有些设计方法采用了功能独立和对象类型等一些便于修改的概念），软件修改不仅困难而且容易出错。 软件维护不是一项有吸引力的工作，从事这项工作令人缺乏成就感。 5.1.3 维护的过程 * 1. 维护组织 2. 维护文档 维护申请表、维护报告、维护记录。 3. 维护的过程 （1）提出申请 （2）安排维护 （2）维护和记录 （3）维护的复审 5.1.4 维护的副作用 * 所谓软件维护的副作用，就是指由于修改而导致的错误或其他多余动作的发生。 编码副作用 数据副作用 文档副作用 修改数据的副作用 * （1）重新定义局部常量或全程常量； （2）重新定义记录格式或文件格式； （3）改变一个数组或高阶数据结构的大小； （4）修改全程变量； （5）重新初始化控制标记或指针； （6）重新排列输入输出或子程序的自变量。 修改数据的副作用可以通过完善的设计文档来加以限制。这种文档描述了数据结构，并且提供了一种把数据元素、记录、文件及其它结构与软件模块联系起来的交叉对照功能。 修改文档的副作用 * 维护应该着眼于整个软件配置，而不只是源程序代码的修改。如果源代码的修改没有反映在设计文档或用户文档中时，就会发生文档的副作用。 每当对数据流图、软件结构、模块算法过程和其它有关的特征进行修改时，必须同时对相应的文档资料进行更新。 在软件再次交付使用之前，对整个软件配置进行评审将大大减少文档的副作用。实际上，某些维护申请的提出只是由于用户文档不够清楚。这时，只需对文档进行维护即可，并不要求修改软件设计或源程序。 修改编码的副作用 * （1）对子程序的删除或修改； （2）对语句标号的删除或修改； （3）对标识符的删除或修改； （4）为改进程序执行性能所做的修改： （5）改变文件的打开或关闭； （6）对逻辑运算符的修改； （7）把设计的修改翻译成程序代码的修改； （8）对判定的边界条件所做的修改。 为确保编码修改没有引入新的错误，应进行严格的回归测试。一般情况下，通过回归测试，可以发现并纠正修改编码所带来的副作用。 维护的代价 * 软件维护的费用稳步上升，目前已达到80%。 维护工作量的模型 M=P+K*exp(c-d) M-维护用的总工作量 P-生产性工作量 K-经验系数 c-复杂程度（非结构化设计和缺少文档都会增加软件的复杂程度） d-维护人员对软件的熟悉程度 维护中的问题 * 与软件维护有关的绝大多数问题的根源在于计划阶段和开发阶段的工作有缺点。 典型问题 读懂原开发人员写的程序通常相当困难。 软件人员的流动性，使得软件维护时，很难与原开发人员沟通。 没有文档或文档严重不足。 软件设计时，欠考虑软件的可修改性 频繁的软件升级，要追踪软件的演化变得很困难，使软件难以修改。 5.2 软件的可维护性 * 软件可维护性指软件被理解、改正、调整和改进的难易程度。 可维护性是指导软件工程各个阶段工作的一条基本原则，也是软件工程追求的目标之一。 5.2.1 决定可维护性的因素 * 是否拥有