8章节维护.pptVIP

第8章 维 护;8.1 软件维护的定义 8.2 软件维护的特点 8.3 软件维护过程 8.4 软件的可维护性 8.5 维护的副作用 8.6 维护复审 ;维护是软件生命周期的最后一个阶段，其任务是保证软件在一个相当长的时期能够正常运行。 大型软件的维护成本高达开发成本的4倍左右。 国外许多软件开发组织把60%以上的人力用于维护已有的软件。 软件工程的目的 提高软件的可维护性 减少软件维护的工作量 降低软件系统的总成本。;软件维护就是在软件交付之后，为了改正错误或满足新的需要而修改软件的过程。 改正性维护。改正软件中存在的错误。 适应性维护。使软件适应变化了的环境,它是既必要又经常的维护活动。 完善性维护。使软件适应用户新的功能或修改的要求。 预防性维护。当为了改进未来的可维护性或可靠性，或为了给未来的改进奠定更好的基础而修改软件时出现了。; 在全部维护活动中一半以上是完善性维护。 完善性维护占全部维护活动的50%～66% 改正性维护占17%～21% 适应性维护占18%～25% 其他维护活动只占4%左右。 ;软件维护中的比重;8.2 软件维护的特点;非结构化维护;结构化维护 如果有一个完整的软件配置，那么维护工作从评价设计文档开始； 它是在软件开发的早期应用软件工程方法学的结果。 虽然有了软件的完整配置并不能保证维护中没有问题，但是确实能减少精力的浪费并且能提高维护的总体质量。;软件维护代价极高，既破财，又伤神； 有形的代价指投入的人力物力； 1970年用于维护已有软件的费用只占软件总预算的35%～40%； 1980年上升为40%～60%； 1990年上升为70%～80%。 ;当看来合理的有关改错或修改的要求不能及时满足时将引起用户不满； 由于维护时的改动，在软件中引入了潜伏的错误，从而降低了软件的质量； 当必须把软件工程师调去从事维护工作时，将在开发过程中造成混乱。也有人称之为“机会成本”，即为了得到某种东西必然要放弃的东西； 软件维护的最后一个代价是生产率的大幅度下降，这种情况在维护旧程序时常常遇到。;维护工作的种类;下述表达式给出维护工作量的一个模型： M=P+K×exp(c-d) M是维护用的总工作量 P是生产性工作量 K是经验常数 c是复杂程度(非结构化设计和缺少文档都会增加软件的复杂程度) d是维护人员对软件的熟悉程度。 该模型表明，如果软件的开发途径不好(即，没有使用软件工程方法学)，而且原来的开发人员不能参加维护工作，那么维护工作量和费用将指数地增加。;影响维护代价的非技术因素;影响维护代价的技术因素;（1） 理解别人写的程序通常非常困难，而且困难程度随着软件配置成分的减少而迅速增加。 （2） 需要维护的软件往往没有合格的文档，或者文档资料显著不足。认识到软件必须有文档仅仅是第一步，容易理解的并且和程序代码完全一致的文档才真正有价值。;（3） 当要求对软件进行维护时，不能指望由开发人员给我们仔细说明软件。 （4） 绝大多数软件在设计时没有考虑将来的修改。除非使用强调模块独立原理的设计方法学，否则修改软件既困难又容易发生差错。 （5） 软件维护不是一项吸引人的工作。形成这种观念很大程度上是因为维护工作经常遭受挫折。 ;维护过程本质上是修改和压缩了的软件定义和开发过程，而且事实上远在提出一项维护要求之前，与软件维护有关的工作已经开始了。 首先,必须建立一个维护组织，随后必须确定报告和评价的过程，而且必须为每个维护要求规定一个标准化的事件序列。 此外，还应该建立一个适用于维护活动的记录保管过程，并且规定复审标准。; 图8.1 维护组织;2. 维护报告 应该用标准化的格式表达所有软件维护要求。 软件维护人员通常给用户提供空白的维护要求表——有时称为软件问题报告表。 如果遇到了一个错误，那么必须完整描述导致出现错误的环境(包括输入数据、全部输出数据以及其他有关信息)。 对于适应性或完善性的维护要求，应该提出一个简短的需求说明书。;维护要求表是一个外部产生的文件，它是计划维护活动的基础。 软件组织内部应该制定出一个软件修改报告，它给出下述信息： (1) 满足维护要求表中提出的要求所需要的工作量； (2) 维护要求的性质； (3) 这项要求的优先次序； (4) 与修改有关的事后数据。 在拟定进一步的维护计划之前，把软件修改报告提交给变化授权人审查批准。;3. 维护的事件流 图8.2描绘了由一项维护要求而引出的一串事件。当存在不同意见时必须协商解决。;不管维护类型如何，都需要进行同样的技术工作。包括修改软件设计、复查、必要的代码修改、单元测试和集成测试(包括使用以前的测试方案的回归测试)、验收测试和复审。 不同类型的维护强调的重点不同，但是基本途径是相同的。;维护事件流中最后一个事件是复审，它再次检验