搜索
第8章维护8.1软件维护的定义8.2软件维护的特点8.3软件维护过程8.4软件的可维护性8.5预防性维护8.6软件再工程过程1（一）定义软件维护是软件生存周期的最后一个阶段，它是在软件交付使用之后，为了改正错误或满足新的要求而修改软件的过程。因此不属于系统开发过程。据统计一个大、中型软件的开发周期一般为1-3年，有效运行周期可达5-10年。在这段时间里，我们除了要改正软件中残留的错误外，更多的是要随着计算机技术的发展，不断更新软件版本，适应改善了的软、硬件运行环境，增加软件产品的新需求，这些都属于维护范畴的工作。2（二）分类1.改正性维护改正性维护的目的就在于纠正在开发期间未能发现的遗留错误。这种为了纠错而进行的诊断和改正过程我们称为改正性维护。改正性维护通常包括以下几方面的内容：（1）改正处理上的错误；（2）改正性能上的错误；（3）改正程序编制的错误。改正性维护大约占软件维护总工作量的21％。32.适应性维护为适应变化了的环境界面而修改软件的活动，称为适应性维护。包括：（1）因硬件或支撑软件改变引起的变化；（2）将软件移植到新的机种上运行；（3）因数据环境的变化而做的变更。这类维护大约占软件维护总工作量的25％。43.完善性维护为了满足用户要求，就得对软件进行修改和扩充，我们称这种维护为完善性维护。完善性维护主要包括：（1）提高处理效率；（2）提高性能。在整个维护工作中，完善性维护大约占50％左右，区居第一位。54.预防性维护为了改进软件未来的可维护性和可靠性，或者为了给未来的改进提供更好的基础，而对软件进行的修改，通常称作预防性维护。预防性维护大约占软件维护总工作量的4％左右。改正性维护是改正软件中原有的错误，所以对软件的修改一般不会导致文档的修改，而适应性和完善性维护则不同，这两类维护一般要导致文档的修改。6（三）特点1.结构化维护和非结构化维护配置评价设计计划途径修改设计重新编码评价代码？复查重新编码复查维护要求交付使用软件代码72.维护代价软件的维护代价包括有形代价、无形代价和生产率代价三部分。（1）有形代价1970年：35％——40％1980年：40％——60％1990年：70％——80％2000年：80％——90％8（2）无形代价是一种无法估量的代价，主要包括：1）当可用资源必须提供给维护工作使用时，将会延误甚至丧失开发良机。2）当合理的有关改错或修改要求不能及时得到满足时，将引起用户的不满，甚至可能失掉用户。3）维护时的改动有可能引入潜在的错误，使软件的质量下降。4）当必须把从事开发工作的软件人员抽去搞维护工作时，开发工作的正常秩序就被打乱了。9（3）生产率代价据Gausler在1976年的报道，美国空军的飞行控制软件每条指令的开发成本是75美元，而维护成本大约是每条指令4000美元，显然生产率下降了50倍。维护分为两种，一种是生产性活动，如分析评价，修改设计和编写程序代码等。还有一种叫“打滑”活动，也称非生产性活动，如试图理解代码的功能、试图解释数据结构、接口特征等。101979年Belady和Lehman提出维护工作的模型：M=P+K×exp(c-d)其中：M——花在维护上的总工作量；P——生产性工作量；K——经验常数；c——复杂性度量；d——对被维护软件熟悉程度的一种度量。113.维护的问题（1）理解他人写的程序往往是非常困难的，软件配置越少，困难越大。如果程序只有代码而没有文档，则会出现严重的问题。（2）没有合适的文档资料或文档资料太少。首先要认识到软件必须有文档资料，其次文档资料必须是可以理解的并与源程序一致。否则软件修改将很困难，还容易引入新的问题。12（3）对软件进行维护时，经常得不到开发人员的帮助。因为维护时间较长，需要解释软件时，原来写程序的人往往不在现场。（4）大多数软件在设计时没有考虑将来的修改。除非采用强调模块独立原理的设计方法，否则软件的修改将是困难的，并且容易出错。（5）软件维护不是一项吸引人的工作。这是因为维护工作困难大，常使人受到挫折。13（四）软件维护过程维护过程的实质是对软件定义和开发过程的修改和压缩。维护过程的主要任务是：建立维护机构，填写维护报告和评价，为每个维护要求规定一种规范化的处理序列，建立对维护活动的登记制度及规定评价复审的标准。1.维护组织机构中有一名维护管理员总负责，每项维护要求都通过维护管理员转交给相应的系统管理员去评价。系统管理员对维护任务做出评价之后，由变化授权人决定应该进行的活动，最后由系统管理员去执行维护任务。142.维护报告软件维护报告是由软件组织外部产生的维护要求表和软件组织内部作出的软件修改报告两部分构成。(1)满足维护要求表中提出的要求所需要的工作量；(2)维护要求的性质；(3)这项要求的优先次序；(4)预计修改后的状态。153.维护的事件流164.保存维护记录先要确定哪些数据是值得记录的？Swanson提出了下述内容：（1）程序标识；（2）源语句数；（3）机器指令条数；（4）使用的程序设计语言；（5）程序安装的日期；（6）从安装以来程序运行的次数；（7）从安装以来程序失效的次数；（8）程序变动的层次和标识；17（9）因程序变动而增加的源语句数；（10）因程序变动而删除的源语句数；（11）每个改动耗费的人－时数；（12）修改程序的日期；（13）软件工程师的名字；（14）维护要求表的标识；（15）维护类型；（16）维护开始和结束的日期；（17）累计用于维护的人－时数；（18）维护工作的净效益。185.评价维护活动可以对维护工作从以下几方面进行度量：（1）每次程序运行平均失效的次数；（2）花费在每类维护上的总人－时数；（3）平均每个程序、每种语言、每类维护类型所做的程序修改数；（4）维护过程中增加或删除一个源语句平均花费的人－时数；（5）维护每种语言源程序花费的人－时数；（6）一份维护申请表的平均处理时间；（7）不同维护类型所占的百分比。19（五）软件的可维护性1.决定软件可维护性的因素（1）可理解性可理解性表现为外来读者理解软件的结构、功能、接口和内部过程的难易程度。模块化、详细的设计文档、结构化程序设计、源代码内部的文档和良好的高级程序设计语言等，都是软件可理解性的依据和基础。20（2）可测试性诊断和测试的容易程度取决于软件容易理解的程度。良好的设计文档，规范的软件结构、可用的测试工具和调试工具，保存完好的测试报告等对于维护阶段的测试工作是十分重要的。（3）可修改性软件的可修改性与我们前面所介绍的模块独立、耦合、内聚、局部化、控制域与作用域的关系等软件设计原则密切相关。它们都不同程序地影响软件的可修改性。21（4）可移植性软件可移植性指把程序从一种计算环境转移到另一种计算环境的难易程度。（5）可重用性所谓重用指同一事物不做修改或稍加改动就在不同环境中多次重复使用。大量使用可重用的软件构件来开发软件，可以从下述两个方面提高软件的可维护性：1）软件中使用的可重用构件越多，软件的可靠性越高，改正性维护需求越少；2）软件中使用的可重用构件越多，适应性和完善性维护也就越容易。222.文档软件系统的文档分为用户文档和系统文档两大类。软件文档应该满足以下要求：（1）提供如何使用这个系统；（2）提供怎样安装和管理这个系统；（3）提供系统需求和设计；（4）提供系统的实现和测试。23（1）用户文档用户文档应该简洁、明了、准确，它是用户了解系统的第一步，它应该能使用户获得对系统的准确的初步印象。文档的结构方式应以方便用户阅读为原则，主要包括下述五个方面的内容：1）功能描述——说明系统能做什么；2）安装文档——说明如何安装这个系统以及怎样使系统适应特定的硬件配置；3）使用手册——简要说明系统的使用方法；244）参考手册——详尽描述用户可以使用的所有系统设施以及它们的使用方法，给出出错信息表，解释系统可能产生的各种出错信息的含义；5）操作员指南——说明操作员应如何处理使用中出现的各种情况。25（2）系统文档系统文档是指软件工程中系统设计的三个过程的设计资料，即定义过程（含问题定义，可行性研究，需求分析）、开发过程（含总体设计，详细设计，编码，测试）、维护过程的设计资料。这些描述系统设计，实现和测试的文档对于理解程序和维护程序是十分重要的。263.可维护性复审可维护性是所有软件都应该具备的基本要素之一。因此，在开发软件的过程中，必须保证软件具有可理解性，可测试性，可修改性三种因素。努力提高每个阶段软件的可维护性同时着重在每个阶段结束前的技术审查和管理复审中对可维护性进行复审。27在需求分析阶段的复审过程中，应该对将来要改进的部分，可能会修改的部分加以注意并指明；应该讨论软件的可移植性问题，并且考虑可能影响软件维护的系统界面。在设计复审期间，应该从容易修改、模块化和功能独立的目标出发，评价软件的结构和过程，设计中应该对将来可能修改的部分预作准备。28编码复审应该强调编码风格和内部说明文档这两个影响可维护性的因素。每个测试步骤都有可以暗示在软件正式交付使用前，程序中可能需要做预防性维护的部分。在测试结束时进行最正式的可维护性复审，也称配置复审，目的是保证软件配置的所有成分是完整的、一致的和可理解的。在完成了每项维护工作之后，必须对软件维护本身进行仔细认真的复审。29（六）软件再工程过程预防性维护也称软件再工程。301.库存目录分析对软件组织都应该保存其拥有的每个应用系统都进行预防性维护是不现实的，也是不必要的。一般说来，下述3类程序有可能成为预防性维护的对象：（1）该程序将在今后数年内继续使用；（2）当前正在成功地使用着该程序；（3）可能在最近的将来要对该程序做较大程度的修改或扩充。应该仔细分析库存目录，按照业务重要程度、寿命、当前可维护性、预期的修改次数等标准，把库中的应用系统排序，从中选出再工程的候选者，然后合理地分配再工程所需要的资源。312.文档重构老程序固有的特点是缺乏文档。根据具体情况可采用下面3种方法之一来处理问题：（1）如果一个程序是相对稳定的，正在走向生命的终点，而且可能不会再修改它，则不必为它建立文档。（2）为了便于今后的维护，必须更新文档，但是由于资源有限，应该采用“使用时建文档”的方法，也就是说，不是一下子把某应用系统的文档全部都重建起来，而是只建立系统中当前正在修改的那些部分的完整文档。（3）如果某应用系统是用户完成业务工作的关键，而且必须重构全部文档，则仍然应该设法把文档工作减少到必需的最小量。323.逆向工程软件的逆向工程是，分析程序以便在比源代码更高的抽象层次上创建出程序的某种描述的过程，也就是说，逆向工程是一个恢复设计结果的过程。4.代码重构某些老程序的体系结构比较合理，但是，一些模块的编码方式却是难于理解、测试和维护的。在这种情况下，可以重构这些模块的代码。通常，代码重构并不修改程序的体系结构，它只关注个体模块的设计细节以及在模块中定义的局部数据结构。如果重构扩展到模块边界以外并涉及软件体系结构，则重构变成了正向工程。335.数据重构对数据体系结构差的程序很难进行适应性和完善性维护，因此，数据体系结构比源代码对程序的长期生存力有更大影响。数据重构是一种全范围的再工程活动。由于数据重构对程序体系结构及程序中的算法有很大影响，对数据的修改必然会导致程序体系结构或代码层的改变。346.正向工程正向工程也称为更新或再造。正向工程过程应用现代软件工程的原理、概念、技术和方法，重新开发现有的某个应用系统。在大多数情况下，经过正向工程过程后得出的软件，不仅重新实现现有系统的功能，而且增加了新功能，提高了整体性能。35