8.软件工程 维护.pptVIP

维护 维护 8.1 软件维护的定义 8.2 软件维护的特点 8.3 软件维护过程 8.4 软件的可维护性 8.5 预防性维护 8.6 软件再工程过程 8.7 小结 维护阶段是软件生命周期的最后一个阶段，其基本任务是保证软件在一个相当长的时期能够正常运行。 软件维护需要的工作量很大，平均说来，大型软件的维护成本高达开发成本的4倍左右。目前国外许多软件开发组织把60%以上的人力用于维护已有的软件，而且随着软件数量增多和使用寿命延长，这个百分比还在持续上升。 软件工程的目的是要提高软件的可维护性，减少软件维护所需要的工作量，降低软件系统的总成本。 8.1 软件维护的定义 软件维护就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。 有4项活动，具体地定义软件维护： 改正性维护 适应性维护 完善性维护 预防性维护 软件维护绝不仅限于纠正使用中发现的错误，在全部维护活动中一半以上是完善性维护。 国外的统计数字表明，完善性维护占全部维护活动的50%～66%，改正性维护占17%～21%，适应性维护占18%～25%，其他维护活动只占4%左右。 上述4类维护活动都必须应用于整个软件配置，维护软件文档和维护软件的可执行代码是同样重要的。 8.2 软件维护的特点 结构化维护 非结构化维护 结构化维护与非结构化维护差别巨大 非结构化维护 如果软件配置的惟一成分是程序代码： 那么维护活动从艰苦地评价程序代码开始 常常由于程序内部文档不足而使评价更困难 对于软件结构、全程数据结构、系统接口、性能和(或)设计约束等经常会产生误解 对程序代码所做的改动的后果也是难于估量的 因为没有测试方面的文档，所以不可能进行回归测试 非结构化维护需要付出很大代价(浪费精力并且遭受挫折的打击) 这种维护方式是没有使用良好定义的方法学开发出来的软件的必然结果。 结构化维护 如果有一个完整的软件配置存在： 那么维护工作从评价设计文档开始，确定软件重要的结构特点、性能特点以及接口特点； 估量要求的改动将带来的影响，并且计划实施途径。 然后首先修改设计并且对所做的修改进行仔细复查。 接下来编写相应的源程序代码； 使用在测试说明书中包含的信息进行回归测试； 最后，把修改后的软件再次交付使用。 这是在软件开发的早期应用软件工程方法学的结果。 虽然有了软件的完整配置并不能保证维护中没有问题，但是确实能减少精力的浪费并且能提高维护的总体质量。 8.2.2 维护的代价高昂 在过去的几十年中，软件维护的费用稳步上升。 1970年用于维护已有软件的费用只占软件总预算的35%～40% 1980年上升为40%～60% 1990年上升为70%～80%。 维护费用只不过是软件维护的最明显的代价，其他一些现在还不明显的代价将来可能更为人们所关注。 因为可用的资源必须供维护任务使用，以致耽误甚至丧失了开发的良机，这是软件维护的一个无形的代价。 用于维护工作的劳动可以分成生产性活动(例如，分析评价，修改设计和编写程序代码等)和非生产性活动(例如，理解程序代码的功能，解释数据结构、接口特点和性能限度等)。 下述表达式给出维护工作量的一个模型： M=P+K×exp(c-d) 其中： M是维护用的总工作量，P是生产性工作量，K是经验常数，c是复杂程度(非结构化设计和缺少文档都会增加软件的复杂程度)，d是维护人员对软件的熟悉程度。 上面的模型表明，如果软件的开发途径不好(即，没有使用软件工程方法学)，而且原来的开发人员不能参加维护工作，那么维护工作量和费用将指数地增加。 8.2.3 维护的问题很多 与软件维护有关的绝大多数问题，都可归因于软件定义和软件开发的方法有缺点。在软件生命周期的头两个时期没有严格而又科学的管理和规划 下面列出和软件维护有关的部分问题： （1） 理解别人写的程序通常非常困难，而且困难程度随着软件配置成分的减少而迅速增加。如果仅有程序代码没有说明文档，则会出现严重的问题。 （2） 需要维护的软件往往没有合格的文档，或者文档资料显著不足。认识到软件必须有文档仅仅是第一步，容易理解的并且和程序代码完全一致的文档才真正有价值。 （3） 当要求对软件进行维护时，不能指望由开发人员给我们仔细说明软件。 （4） 绝大多数软件在设计时没有考虑将来的修改。除非使用强调模块独立原理的设计方法学，否则修改软件既困难又容易发生差错。 （5） 软件维护不是一项吸引人的工作。形成这种观念很大程度上是因为维护工作经常遭受挫折。 软件工程至少部分地解决了与维护有关的每一个问题。 8.3 软件维护过程 维护过程本质上是修改和压缩了的软件定义和开发过程 必须建立一个维护组织，随后必须确定报告和评价的过程，而且必须为每个维护要求规定一个标准化