第9章软件维护ppt课件.ppt

1,第9章 软件维护,2,软件维护,软件维护是软件生命周期的最后一个阶段，它处于系统投入生产性运行以后的时期中，因此不属于系统开发过程。 软件维护需要的工作量非常大，虽然在不同应用领域维护成本差别很大，但是，平均说来，大型软件的维护成本高达开发成本的四倍左右。目前国外许多软件开发组织把60以上的人力用于维护已有的软件，而且随着软件数量增多和使用寿命延长，这个百分比还在持续上升。将来维护工作甚至可能会束缚住软件开发组织的手脚，使他们没有余力开发新的软件。 本书前面各章讲述的软件工程方法学的主要目的就是要提高软件的可维护性，减少软件维护所需要的工作量，降低软件系统的总成本。,3,9.1 软件维护的定义,4,软件维护的定义,所谓软件维护就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。我们可以通过描述软件交付使用后可能进行的四项活动，具体地定义软件维护。因为软件测试不可能暴露出一个大型软件系统中所有潜藏的错误，所以必然会有第一项维护活动：在任何大型程序的使用期间，用户必然会发现程序错误，并且把他们遇到的问题报告给维护人员。我们把诊断和改正错误的过程称为改正性维护。计算机科学技术领域的各个方面都在迅速进步，大约每过若干个月就有新一代的硬件宣告出现，经常推出新操作系统或旧系统的修改版本，时常增加或修改外部设备和其他系统部件；另一方面，应用软件的使用寿命却很容易超过十年，远远长于最初开发这个软件时的运行环境的寿命。因此，适应性维护，也就是为了和变化了的环境适当地配合而进行的修改软件的活动，是既必要又经常的维护活动。,5,软件维护的定义,当一个软件系统顺利地运行时，常常出现第三项维护活动：在使用软件的过程中用户往往提出增加新功能或修改已有功能的建议，还可能提出一般性的改进意见。为了满足这类要求，需要进行完善性维护。这项维护活动通常占软件维护工作的大部分。当为了改进未来的可维护性或可靠性，或为了给未来的改进奠定更好的基础而修改软件时，出现了第四项维护活动。这项维护活动通常称为预防性维护，目前这项维护活动相对说比较稀少。从上述关于软件维护的定义不难看出，软件维护绝不仅限于纠正使用中发现的错误，事实上在全部维护活动中一半以上是完善性维护。国外的统计数字表明，完善性维护占全部维护活动的5066，改正性维护占1721，适应性维护占1825，其他维护活动只占4左右。,6,9.2 维护的特点,7,9.2.1 结构化维护与非结构化维护的对比,如果软件配置的唯一成分是程序代码，那么维护活动从艰苦地评价程序代码开始，而且常常由于程序内部文档不足而使评价更困难。诸如软件结构、全程数据结构、系统接口、性能和（或）设计约束等微妙的特点是难于搞清的，而且常常误解了这一类特点。最终对程序代码所做的改动的后果是难于估量的：因为没有测试方面的文档，所以不可能进行回归测试（即为了保证所做的修改没有在以前可以正常使用的软件功能中引入故障而重复过去做过的测试）。可惜，我们正在进行非结构化维护，并且正在为此而付出代价（浪费精力和受挫折），这种维护方式是没有使用良好定义的方法论开发出来的软件的必然结果。,8,9.2.1 结构化维护与非结构化维护的对比,如果有一个完整的软件配置存在，那么维护工作从评价设计文档开始，确定软件重要的结构特点、性能特点以及接口特点；估量要求的改动将带来的影响，并且计划实施途径。然后首先修改设计并且对所做的修改进行仔细复查。接下来编写相应的源程序代码；使用在测试说明书中包含的信息进行回归测试；最后，把修改后的软件再次交付使用。刚才描述的事件构成结构化维护，它是在软件开发的早期应用软件工程方法论的结果。虽然有了软件的完整配置并不能保证维护中没有问题，但是确实能减少精力的浪费并且能提高维护的总体质量。,9,9.2.2 维护的代价,在过去的几十年中，软件维护的费用稳步上升。1970年用于维护已有软件的费用只占软件总预算的3540，1980年上升为4060，1990年上升为7080。维护费用只不过是软件维护的最明显的代价，其他一些现在还不明显的代价将来可能更为人们所关注。因为可用的资源必须供维护任务使用，以致耽误甚至丧失了开发的良机，这是软件维护的一个无形的代价。其他无形的代价还有： 当看来合理的有关改错或修改的要求不能及时满足时将引起用户不满； 由于维护时的改动，在软件中引入了潜伏的故障，从而降低了软件的质量； 当必须把软件工程师调去从事维护工作时，将在开发过程中造成混乱。,10,9.2.2 维护的代价,软件维护的最后一个代价是生产率的大幅度下降，这种情况在维护旧程序时常常遇到。例如，据Gausler在1976年的报道，美国空军的飞行控制软件每条指令的开发成本是75美元，然而维护成本大约是每条指令4000美元，也就是说，生产率下降了50倍以上。用于维护工作的劳动可以分成生产性活动（例如，分析评价，修改设计和编写程序代码等）和非生产性活动（例如，理解程序代码的功能，解释数据结构、接口特点和性能限度等）。下述表达式给以维护工作量的一个模型： MP十K*exp(c-d)其中M是维护用的总工作量，P是生产性工作量，K是经验常数，c是复杂程度（非结构化设计和缺少文档都会增加软件的复杂程度），d是维护人员对软件的熟悉程度。上面的模型表明，如果软件的开发途径不好（即，没有使用软件工程方法论），而且原来的开发人员不能参加维护工作，那么维护工作量（和费用）将指数地增加。,11,9.2.3 维护的问题,与软件维护有关的绝大多数问题，都可归因于软件定义和软件开发的方法有缺点。在软件生命周期的头两个时期没有严格而又科学的管理和规划，几乎必然会导致在最后阶段出现问题。下面列出和软件维护有关的部分问题： 理解别人写的程序通常非常困难，而且困难程度随着软件配置成分的减少而迅速增加。如果仅有程序代码没有说明文档，则会出现严重的问题。 需要维护的软件往往没有合格的文档，或者文档资料显著不足。认识到软件必须有文档仅仅是第一步，容易理解的并且和程序代码完全一致的文档才真正有价值。 当要求对软件进行维护时，不能指望由开发人员给我们仔细说明软件。由于维护阶段持续的时间很长，因此，当需要解释软件时，往往原来写程序的人已经不在附近了。 绝大多数软件在设计时没有考虑将来的修改。除非使用强调模块独立原理的设计方法论，否则修改软件既困难又容易发生差错。 软件维护不是一项吸引入的工作。形成这种观念很大程度上是因为维护工作经常遭受挫折。,12,9.3 维护过程,13,维护过程,维护过程本质上是修改和压缩了的软件定义和开发过程，而且事实上远在提出一项维护要求之前，与软件维护有关的工作已经开始了。首先必须建立一个维护组织，随后必须确定报告和评价的过程，而且必须为每个维护要求规定一个标准化的事件序列。此外，还应该建立一个适用于维护活动的记录保管过程，并且规定复审标准。,14,9.3.1 维护组织,虽然通常并不需要建立正式的维护组织，但是，即使对于一个小的软件开发团体而言，非正式地委托责任也是绝对必要的。每个维护要求都通过维护管理员转交给相应的系统管理员去评价。系统管理员是被指定去熟悉一小部分产品程序的技术人员。系统管理员对维护任务做出评价之后，由变化授权人决定应该进行的活动。,15,16,9.3.2 软件维护申请报告,应该用标准化的格式表达所有软件维护要求。软件维护人员通常给用户提供空白的维护要求表有时称为软件问题报告表，这个表格由要求一项维护活动的用户填写。如果遇到了一个错误，那么必须完整描述导致出现错误的环境（包括输入数据，全部输出数据，以及其他有关信息）。对于适应性或完善性的维护要求，应该提出一个简短的需求说明书。如前所述，由维护管理员和系统管理员评价用户提交的维护要求表。 维护要求表是一个外部产生的文件，它是计划维护活动的基础。软件组织内部应该制定出一个软件修改报告，它给出下述信息： 满足维护要求表中提出的要求所需要的工作量； 维护要求的性质； 这项要求的优先次序； 与修改有关的事后数据。,17,9.3.3 维护工作流程,软件维护工作流程如下图所示。第一步是确认维护要求。这需要维护人员与用户反复协商，弄清错误概况以及对业务的影响大小，以及用户希望做什么样的修改，并把这些情况存入故障数据库。然后由维护组织管理员确认维护类型。,18,9.3.3 维护工作流程,19,9.3.3 维护工作流程,在完成软件维护任务之后，进行复查常常是有好处的。一般说来，这种复查试图回答下述问题： 在当前处境下设计、编码或测试的哪些方面能用不同方法进行？ 哪些维护资源是应该有而事实上却没有的？ 对于这项维护工作什么是主要的（以及次要的）障碍？ 要求的维护类型中有预防性维护吗？ 复查对将来维护工作的进行有重要影响，而且所提供的反馈信息对有效地管理软件组织十分重要。,20,8.3.4 保存维护记录,对于软件生命周期的所有阶段而言，以前记录保存都是不充分的，而软件维护则根本没有记录保存下来。由于这个原因，我们往往不能估价维护技术的有效性，不能确定一个产品程序的“优良”程度，而且很难确定维护的实际代价是什么。,21,8.3.4 保存维护记录,Swanson提出了下述内容： 程序标识； 源语句数； 机器指令条数； 使用的程序设计语言； 程序安装的日期； 自从安装以来程序运行的次数； 自从安装以来程序失效的次数； 程序变动的层次和标识； 因程序变动而增加的源语句数； 每个改动耗费的人时数； 因程序变动而删除的源语句数；程序改动的日期； 软件工程师的名字； 维护要求表的标识； 维护类型； 维护开始和完成的日期； 累计用于维护的人时数； 与完成的维护相联系的纯效益。,22,8.3.5 评价维护活动,缺乏有效的数据就无法评价维护活动。如果已经开始保存维护记录了，则可以对维护工作做一些定量度量。至少可以从下述七个方面度量维护工作： 每次程序运行平均失效的次数； 用于每一类维护活动的总人时数； 平均每个程序、每种语言、每种维护类型所做的程序变动数； 维护过程中增加或删除一个源语句平均花费的人时数； 维护每种语言平均花费的人时数； 一张维护要求表的平均周转时间； 不同维护类型所占的百分比。 根据对维护工作定量度量的结果，可以做出关于开发技术、语言选择、维护工作量规划、资源分配及其他许多方面的决定，而且可以利用这样的数据去分析评价维护任务。,23,9.4 程序修改的步骤及修改的副作用,24,9.4.1 分析和理解程序,经过分析,全面、准确、迅速地理解程序 是决定维护成败和质量好坏的关键。因此,软件的可理解性和文档的质量非常重要。为了容易地理解程序,要求自顶向下地理解现有源程序的程序结构和数据结构,可采用以下方法 分析程序结构图 数据跟踪 控制跟踪 在分析过程中,充分阅读和使用程序清单和文档，分析文档的合理性。 充分使用由编译或汇编程序提供的交叉引用表、符号表及其他有用信息。 如有可能，积极参加开发工作。,25,9.4.2 修改程序,对程序的修改,必须事先做出计划,有预谋、周密有效地实施修改。 设计程序的修改计划 修改代码,以适应变化 修改程序的副作用 修改代码的副作用 修改数据的副作用 修改文档的副作用 为控制因修改而引起的副作用,要做到： 按模块把修改分组； 自顶向下地安排所修改模块的顺序； 每次修改一个模块； 对于每个修改了的模块,在安排修改下一个模块之前,要确定这个修改的副作用。,26,9.4.3 重新验证程序,将修改后的程序交付用户之前，需要用以下的方法进行充分的确认和测试,以保证整个修改后的程序的正确性。 静态确认 计算机确认,27,9.5 可维护性,28,9.5.1 决定软件可维护性的因素,1. 可理解性 软件可理解性表现为外来读者理解软件的结构、接口、功能和内部过程的难易程度。模块化、详细的设计文档、结构化设计、源代码内部的文档和良好的高级程序设计语言等等，都对改进软件的可理解性有重要贡献。 2. 可靠性 可靠性表明一个程序按照用户的要求和设计目标,在给定的一段时间内正确执行的概率。 3. 可测试性 诊断和测试的难易程度主要取决于软件容易理解的程度。良好的文档对诊断和测试是至关重要的。此外，软件结构、可用的测试工具和调试工具，以及以前设计的测试过程也都是非常重要的。维护人员应该能够得到在开发阶段用过的测试方案，以便进行回归测试。在设计阶段应该尽力把软件设计成容易测试和容易诊断的。,29,9.5.1 决定软件可维护性的因素,4. 可修改性 软件容易修改的程度和本书第四章讲述的设计原理和规则直接有关。耦合、内聚、局部化、控制域与作用域的关系等等，都影响软件的可修改性。 5. 可移植性 可移植性表明程序转移到一个新的计算环境的可能性大小。或者它表明程序可以容易地、有效地在各种各样的计算环境中运行的容易程度。 6. 效率 效率表明一个程序执行预定功能而又不浪费机器资源的程度。 7. 可使用性 从用户观点出发,把可使用性定义为程序方便、实用、及易于使用的程度。 8. 其他间接定量度量可维护性方法,30,9.5.2 文档,文档是影响软件可维护性的决定因素。由于长期使用的大型软件系统在使用过程中必然会经受多次修改，所以文档比程序代码更重要。 软件系统的文档可以分为用户文档和系统文档两类。用户文档主要描述系统功能和使用方法，并不关心这些功能是怎样实现的；系统文档描述系统设计、实现和测试等各方面的内容。 总的说来，软件文档应该满足下述要求： 必须描述如何使用这个系统，没有这种描述即使是最简单的系统也无法使用； 必须描述怎样安装和管理这个系统； 必须描述系统需求和设计； 必须描述系统的实现和测试，以便使系统成为可维护的。,31,用户文档,用户文档是用户了解系统的第一步，它应该能使用户获得对系统的准确的初步印象。文档的结构方式应该使用户能够方便地根据需要阅读有关的内容。 用户文档至少应该包括下述五方面的内容： 功能描述说明系统能做什么； 安装文档说明怎样安装这个系统以及怎样使系统适应特定的硬件配置； 使用手册简要说明如何着手使用这个系统（应该通过丰富例子说明怎样使用常用的系统功能，还应该说明用户操作错误时怎样恢复相重新启动）； 参考手册详尽描述用户可以使用的所有系统设施以及它们的使用方法，还应该解释系统可能产生的各种出错信息的含义（对参考手册最主要的要求是完整，因此通常使用形式化的描述技术）； 操作员指南（如果需要有系统操作员的话）说明操作员应该如何处理使用中出现的各种情况。,32,系统文档,所谓系统文档指从问题定义、需求说明到验收测试计划这样一系列和系统实现有关的文档。描述系统设计、实现和测试的文档对于理解程序和维护程序来说是极端重要的。和用户文档类似，系统文档的结构也应该能把读者从对系统概貌的了解，引导到对系统每个方面每个特点的更形式化更具体的认识。,33,9.5.3 可维护性复审,可维护性是所有软件都应该具备的基本特点，必须在开发阶段保证软件具有前面所提到的那些可维护因素。在软件工程过程的每一个阶段都应该考虑并努力提高软件的可维护性，在每个阶段结束前的技术审查和管理复审中，应该着重对可维护性进行复审。,34,9.5.3 可维护性复审,在需求分析阶段的复审过程中，应该对将来要改进的部分和可能会修改的部分加以注意并指明；应该讨论软件的可移植性问题，并且考虑可能影响软件维护的系统界面。在正式的和非正式的设计复审期间，应该从容易修改、模块化和功能独立的目标出发，评价软件的结构和过程；设计中应该对将来可能修改的部分预作准备。代码复审应该强调编码风格和内部说明文档这两个影响可维护性的因素。,35,9.5.3 可维护性复审,每个测试步骤都可以暗示在软件正式交付使用前，程序中可能需要做预防性维护的部分。在测试结束时进行最正式的可维护性复审，这个复审称为配置复审。配置复审的目的是保证软件配置的所有成分是完整的、一致的和可理解的，而且为了便于修改和管理已经编目归档了。在完成了每项维护工作之后，都应该对软件维护本身进行仔细认真的复审。,36,9.5.3 可维护性复审,维护应该针对整个软件配置，不应该只修改源程序代码。当对源程序代码的修改没有反映在设计文档或用户手册中时，就会产生严重的后果。每当对数据、软件结构、模块过程或任何其他有关的软件特点做了改动时，必须立即修改相应的技术文档。不能准确反映软件当前状态的设计文档可能比完全没有文档更坏。在以后的维护工作中很可能因文档不完全符合实际而不能正确理解软件，从而在维护中引入过多的错误。用户通常根据描述软件特点和使用方法的用户文档来使用、评价软件。如果对软件的可执行部分的修改没有及时反映在用户文档中，则必然会使用户因为受挫折而产生不满。如果在软件再次交付使用之前，对软件配置进行严格的复审，则可大大减少文档的问题。事实上，某些维护要求可能并不需要修改软件设计或源程序代码，只是表明用户文档不清楚或不准确，因此只需要对文档做必要的维护。,