软件工程理论及应用 教学课件 作者 周屹第10章

第10章软件维护工程软件维护阶段覆盖了从软件交付使用到软件被淘汰为止的整个时期。软件的开发时间可能需要一、二年，甚至更短，但它的使用时间可能要经历几年或几十年。在软件开发过程中始终强调软件的可维护性。原因是，一个应用系统由于需求和环境的变化以及自身暴露的问题，在交付用户使用后，对它进行维护是不可避免的，统计和估测结果表明，信息技术中硬件费用一般占35%，软件占65%，而软件后期维护费用有时竟高达软件总费用的80%，所有前期开发费用仅占20%。对软件而言，“维护”是个不太直观的术语，因为软件产品在重复使用时不会被磨损，并不需要进行象对车辆或电器那样的维护。许多大型软件公司为维护已有软件耗费大量人力、财力。因此，必须建立一套评估、控制和实施软件维护的机制。软件维护需要的工作量非常大。平均说来，大型软件的维护成本高达开发成本的四倍左右。目前国外许多软件开发组织把60%以上的人力用于维护已有的软件，而且随着软件数量增多和使用寿命延长，这个百分比还在持续上升。将来维护工作甚至可能会束缚住软件开发组织的手脚，使他们没有余力开发新的软件。10.1软件维护案例介绍10.2软件维护概述10.2.1软件维护的类型10.2.2软件维护的困难10.2.3软件维护的费用10.2.4软件维护的方式10.3软件系统的维护10.3.1概述10.3.2软件维护的过程10.3.3软件维护技术10.3.4影响维护工作量的因素10.3.5软件维护的策略10.3.6维护成本10.1软件维护案例介绍维护发生在一个软件产品发布之后。普遍地估计软件70%左右的费用集中于维护。如果疏忽这个方面，软件品质的研究是不会令人满意的。文档驱动的软件维护主要包括用户文档和系统文档。用户文档是用户了解系统的第一步，它应该能使用户获得对系统的准确的初步印象。文档的结构方式应该使用户能够方便地根据需要阅读有关的内容。用户文档至少应该包括下述5方面的内容：(1)功能描述，说明系统能做什么；(2)安装文档，说明怎样安装这个系统以及怎样使系统适应特定的硬件配置；(3)使用手册，简要说明如何着手使用这个系统(应该通过丰富例子说明怎样使用常用的系统功能，还应该说明用户操作错误时怎样恢复和重新启动)；(4)参考手册，详尽描述用户可以使用的所有系统设施以及它们的使用方法，还应该解释系统可能产生的各种出错信息的含义(对参考手册最主要的要求是完整，因此通常使用形式化的描述技术)；(5)操作员指南(如果需要有系统操作员的话)，说明操作员应该如何处理使用中出现的各种情况。上述内容可以分别作为独立的文档，也可以作为一个文档的不同分册，具体做法应该由系统规模决定。10.2软件维护概述一种软件产品在重复的使用中是不会磨损的，因此并不需要象汽车或电视机那样的”维护”。事实上，这个词被软件人员用以描述一些重要的和一些并不重要的活动。重要的部份是指修改：当计算机系统的规格改变了，其反映了外部的世界的改变，因此系统自己也必须要改变。并不重要的部份是指后期除错：首先移除那些不应该在那里的错误。软件维护是指在软件运行或维护阶段对软件产品所进行的修改。生存周期的最后一个阶段，所有活动都发生在软件交付并投入运行之后。软件维护强调必须在现有系统的限定和约束条件下实施，维护活动根据起因可分为改正性维护、适应性维护、改善性维护和预防性维护四类。10.2.1软件维护的类型改正性维护：在软件交付使用后，由于开发时测试得不彻底或不完全，在运行阶段会暴露一些开发时未能测试出来的错误。为了识别和纠正软件错误，改正软件性能上的缺陷，避免实施中的错误使用，应当进行的诊断和改正错误的过程，这就是改正性维护。10.2.2软件维护的困难软件维护的困难性主要是由于软件需求分析和开发方法的缺陷造成的。软件生存周期中的开发阶段没有严格而又科学的管理和规划，几乎必然会导致在最后阶段出现问题。10.2.3软件维护的费用在过去的几十年中，软件维护的费用稳步上升。维护费用只不过是软件维护的最明显的代价，其他一些现在还不明显的代价将来可能更为人们所关注。因为可用的资源必须供维护任务使用，以致耽误甚至丧失了开发新软件的良机，这是软件维护的一个无形的代价。其他无形的代价还有：当看来合理的有关改错或修改的要求不能及时满足时将引起用户不满；由于维护时的改动，在软件中引入了潜伏的故障，从而降低了软件的质量；当必须把软件工程师调去从事维护工作时，将在开发过程中造成混乱。10.2.4软件维护的方式软件维护可分为，结构化与非结构化的维护。如果软件配置的唯一成分是程序代码，那么维护活动从艰苦地评价程序代码开始，而且常常由于程序内部文档不足而使评价更困难。诸如软件结构、全程数据结构、系统接口、性能或设计约束等微妙的特点是难于搞清的，而且常常误解了这一类特点。最终对程序代码所做的改动的后果是难于估量的。因为没有测试方面的文档，所以不可能进行回归测试。10.3软件系统的维护

10.3.1概述维护过程本质上是修改和压缩了的软件定义和开发过程，而且事实上远在提出一项维护要求之前，与软件维护有关的工作已经开始了。首先必须建立一个维护组织，随后必须确定报告和评价的过程，而且必须为每个维护要求规定一个标准化的事件序列。此外，还应该建立一个适用于维护活动的记录保管过程，并且规定复审标准。10.3.2软件维护的过程1.维护组织虽然通常并不需要建立正式的维护组织，但是，即使对于一个小的软件开发团体而言，非正式地委托责任也是绝对必要的。每个维护要求都通过维护管理员转交给相应的系统管理员去评价。系统管理员是被指定去熟悉一小部分产品程序的技术人员。2.维护报告所有软件维护申请应按规定的方式提出，维护机构通常提供“维护申请报告”或称“软件问题报告”由申请维护的用户填写。维护机构内部要写“软件修改报告”。软件修改报告指明：为满足维护申请报告提出的需求所需的工作量、本次维护活动的类别、本次维护请求的优先级、本次修改的背景数据。在拟定进一步维护计划前，软件修改报告要提交给修改决策机构，供进一步规划维护活动使用。3.维护的事件流图10.3描绘了由一项维护要求而引出的一串事件。首先应该确定要求进行的维护的类型。用户常常把一项要求看作是为了改正软件的错误（即改正性维护），而开发人员可能把同一项要求看作是适应性或完善性维护。当存在不同意见时必须协商解决。4.保存维护记录对于软件生命周期的所有阶段而言，以前记录保存都是不充分的，而软件维护则根本没有记录保存下来。由于这个原因，往往不能估价维护技术的有效性，不能确定一个产品程序的“优良”程度，而且很难确定维护的实际代价是什么。10.3.3软件维护技术1.面向维护的技术面向维护的技术涉及软件开发的所有阶段。在需求分析阶段，对用户的需求进行严格的分析定义，使之没有矛盾和易于理解，可以减少软件中的错误。2.维护支援技术维护支援技术包括下列各方面的技术：(1)信息收集。(2)错误原因分析。(3)软件分析与理解。(4)维护方案评价。(5)代码与文档修改。(6)修改后的确认。(7)远距离的维护。10.3.4影响维护工作量的因素软件的维护受各种因素的影响。设计、编码和测试时漫不经心，软件配置不全都会给维护带来困难。除了与开发方法有关的因素外，还有下列与开发环境有关的因素：是否拥有一组训练有素的软件人员；系统结构是否可理解；是否使用标准的程序设计语言；是否使用标准的操作系统；文档的结构是否标准化；测试用例是否合适；是否已有嵌入系统的调试工具；是否有一台计算机可用于维护。除此之外，软件开发时的原班人马是否能参加维护也是一个值得考虑的因素。10.3.5软件维护的策略1.降低改正性维护成本的策略显然，软件中包含的错误越少，改正性维护的成本也就越低，但是，要生成100%可靠的软件通常成本太高，并不一定合算。然而通过使用先进技术仍然可以大大提高软件的可靠性，从而减少改正性维护的需求。2.降低适应性维护成本的策略3.降低完善性维护成本的策略上述的减少前两类维护成本的策略，通常也能降低完善性维护的成本。特别是数据库管理系统、程序自动生成系统、软件开发环境、第四代语言和应用软件包，可明显减少维护工作量。此外，在需求分析过程中准确地预测用户将来可能提出的需求，并且在设计时为将来可能提出的需求预先做准备，显然是降低完善性维护成本的有力措施。10.3.6维护成本

影响维护成本的非技术因素主要有：（1）应用域的复杂性。如果应用域问题已被很好地理解，需求分析工作比较完善，那么维护代价就较低。反之维护代价就较高。（2）开发人员的稳定性。如果某些程序的开发者还在，让他们对自己的程序进行维护，那么代价就较低。如果原来的开发者已经不在，只好让新手来维护陌生的程序，那么代价就较高。（3）软件的生命期。越是早期的程序越难维护。一般地，软件的生命期越长，维护代价就越高。生命期越短，维护代价就越低。（4）商业操作模式变化对软件的影响。比如财务软件，对财务制度的变化很敏感。财务制度一变动，财务软件就必须修改。软件维护的副作用指，由于维护或在维护过程中其他一些不期望的行为引入的错误，副作用大致可分为三类：代码副作用：修改或删除子程序；修改或删除语句标号；修改或删除标识符；为提高执行效率而做的修改；修改文件的open、close操作；修改逻辑操作符；由设计变动引起的代码修改；修改对边界条件的测试。数据副作用：局部和全局常量的再定义；记录或文件格式的再定义；增减数据或其他复杂数据结构的体积；修改全局数据；重新初始化控制标志和指针；重新排列I/O表或子程序参数表。文档的副作用：维护应统一考虑整个软件配置，而不仅仅是源代码。否则，由于在设计文档和用户手册中