软件工程第八章(维护).

《软件工程导论》（第5版）第8章维护软件生存周期问题定义软件定义可行性研究需求分析总体设计系统设计详细设计软件生命周期软件开发编码和单元测试系统实现综合测试运行维护第8章维护软件维护是软件生命周期的最后一个阶段，它处于系统投入生产性运行以后的时期中，因此不属于系统开发过程。软件维护的基本任务是保证软件在一个相当长的时期能够正常运行。软件维护需要的工作量非常大，虽然在不同应用领域维护成本差别很大，但是，平均说来，大型软件的维护成本高达开发成本的四倍左右。8.1.1软件维护定义所谓软件维护就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。软件维护包括下述4项活动。诊断和改正错误的过程：改正性维护为了和变化了的环境适当地配合而进行的修改软件的活动：适应性维护为了满足在使用软件的过程中用户的建议和改进意见而作的维护：完善性维护为了给未来的改进奠定更好的基础而修改软件：预防性维护在软件交付使用后，因开发时测试的不彻底、不完全，必然会有部分隐藏的错误遗留到运行阶段。这些隐藏下来的错误在某些特定的使用环境下就会暴露出来。为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用，应当进行的诊断和改正错误的过程就叫做改正性维护。改正性维护的工作量占全部维护活动的17%～21%。1、改正（纠错）性维护适应性维护，也就是为了和变化了的环境适当地配合而进行的修改软件的活动，是既必要又经常的维护活动。外部环境（新的硬、软件配置）数据环境（数据库、数据格式、数据输入/输出方式、数据存储介质）可能发生变化。适应性维护的工作量占全部维护活动的18%～25%2、适应性维护在软件的使用过程中，用户往往会对软件提出新的功能与性能要求。为了满足这些要求，需要修改或再开发软件，以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性。这种情况下进行的维护活动叫做完善性维护。3、完善性维护实践表明，在几种维护活动中，完善性维护所占的比重最大。即大部分维护工作是改变和加强软件，而不是纠错。完善性维护不一定是救火式的紧急维修，而可以是有计划、有预谋的一种再开发活动。事实证明，来自用户要求扩充、加强软件功能、性能的维护活动约占整个维护工作的50％以上。3、完善性性维护预防性维护是为了提高软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础。预防性维护定义为：采用先进的软件工程方法对需要维护的软件或软件中的某一部分（重新）进行设计、编制和测试。在整个维护活动中，预防性维护占很小的比例，只占5%。4、预防性维护综述在整个软件维护阶段所花费的全部工作量中，完善性维护占了几乎一半的工作量。软件维护活动所花费的工作占整个生存期工作量的70%以上，这是由于在漫长的软件运行过程中需要不断对软件进行修改，以改正新发现的错误、适应新的环境和用户新的要求，这些修改需要花费很多精力和时间，而且有时会引入新的错误。8.1.1软件维护定义三类维护占维护在软件生总维护比例存期所占比例8.2维护的特点一．结构化维护与非结构化维护的差别巨大1.非结构化维护如果软件配置的唯一成分是程序代码，那么维护活动从艰苦地评价程序代码开始，而且常常由于程序内部文档不足而使评价更困难。而且对程序代码所做的改动的后果是难于估量的：因为没有测试方面的文档，所以不可能进行回归测试。非结构化维护付出代价高昂。8.2维护的特点2.结构化维护如果有一个完整的软件配置存在，那么维护工作从评价设计文档开始，确定软件重要的结构特点、性能特点以及接口特点；估量要求的改动将带来的影响，并且计划实施途径。然后首先修改设计并且对所做的修改进行仔细复查。接下来编写相应的源程序代码；使用在测试说明书中包含的信息进行回归测试；最后，把修改后的软件再次交付使用。结构化维护能减少精力浪费并且能提高维护的总体质量。8.2维护的特点二、维护成本有形的软件维护成本是花费了多少钱，无形的维护成本有更大的影响。一些合理的修复或修改请求不能及时安排，使得客户不满意；变更的结果引入新的故障，使得软件整体质量下降；把软件人员抽调到维护工作中，干扰了软件开发工作。软件维护的代价是降低了生产率，在做老程序的维护时非常明显。例如，开发每一行源代码耗资25美元，维护每一行源代码需要耗资1000美元。8.2维护的特点维护工作量的一个模型：M＝P＋K*exp（c-d）其中：M是维护用的总工作量，P是生产性工作量，K是经验常数，c是因缺乏好的设计和文档而导致复杂性的度量），d是维护人员对软件的熟悉程度。模型表明，如果软件的开发途径不好(即，没有使用软件工程方法学)，而且原来的开发人员不能参加维护工作，那么维护工作量和费用将指数地增加。影响维护工作量的因素在软件的维护过程中，需要花费大量的工作量，从而直接影响了软件维护的成本。许多软件在开发时并未考虑将来的修改，为软件的维护带来许多问题。系统大小：系统越大，理解掌握起来越困难。系统越大，所执行功能越复杂。因而需要更多的维护工作量。程序设计语言：使用强功能的程序设计语言可以控制程序的规模。语言的功能越强，生成程序的模块化和结构化程度越高，所需的指令数就越少，程序的可读性越好。系统年龄：老系统随着不断的修改，结构越来越乱；维护人员经常更换，程序又变得越来越难于理解。许多老系统在当初并未按照软件工程的要求进行开发，因而没有文档，或文档太少。在长期的维护过程中文档在许多地方与程序实现变得不一致，在维护时就会遇到很大困难。数据库技术的应用：使用数据库，可以简单而有效地管理和存储用户程序中的数据，还可以减少生成用户报表应用软件的维护工作量。先进的软件开发技术：在软件开发时，若使用能使软件结构比较稳定的分析与设计技术，及程序设计技术，如面向对象技术、复用技术等，可减少大量的工作量。8.2维护的特点三．维护的问题与软件维护有关的绝大多数问题，都可归因于软件定义和软件开发的方法有缺点。在软件生命周期的头两个时期没有严格而又科学的管理和规划，几乎必然会导致在最后阶段出现问题。8.2维护的特点和软件维护有关的部分问题：理解别人写的程序通常非常困难，而且困难程度随着软件配置成分的减少而迅速增加。如果仅有程序代码没有说明文档，则会出现严重的问题。需要维护的软件往往没有合格的文档，或者文档资料显著不足。认识到软件必须有文档仅仅是第一步，容易理解的并且和程序代码完全一致的文档才真正有价值。当要求对软件进行维护时，不能指望由开发人员给我们仔细说明软件。由于维护“阶段持续的时间很长，因此，当需要解释软件时，往往原来写程序的人已经不在附近了。8.2维护的特点绝大多数软件在设计时没有考虑将来的修改。除非使用强调模块独立原理的设计方法论，否则修改软件既困难又容易发生差错。软件维护不是一项吸引人的工作。形成这种观念很大程度上是因为维护工作经常遭受挫折。8.3软件维护过程维护过程本质上是修改和压缩了的软件定义和开发过程。为了有效地进行软件维护，应事先就开始做组织工作。首先建立一个维护组织确定报告及评价的过程为每一个维护要求规定一个标准化的事件序列建立一个适用于维护活动的记录保管过程，并且规定复审标准8.3软件维护过程1.维护组织维护组织维护申请提交给维护管理员，他把申请交给某个系统监督员去评价。一旦做出评价，由修改负责人确定如何进行修改。在修改程序的过程中，由配置管理员严格把关，控制修改的范围，对软件配置进行审计。在维护之前，就把责任明确下来，可以减少维护过程中的混乱。维护修改建议分析修改建议是否合理提交管理部门审查是否同意修改撤销NYNY进行测试提交管理部门审批是否批准更新主文档Y更新其他文档提交使用修改N软件维护的管理流程8.3软件维护过程2.维护报告应该用标准化的格式表达所有软件维护要求。软件维护人员给用户提供空白的维护要求——有时称为软件问题报告表，由要求一项维护活动的用户填写。如果遇到了一个错误，那么必须完整描述导致出现错误的环境（包括输入数据，全部输出数据，以及其他有关信息）。对于适应性或完善性的维护要求，应该提出一个简短的需求说明书。由维护管理员和系统管理员评价用户提交的维护要求表。8.3软件维护过程3.维护的事件流8.3软件维护过程4.保存维护记录应该为每项维护工作都收集下述数据：（1）程序标识；（2）源语句数；（3）机器指令条数；（4）使用的程序设计语言；（5）程序安装的日期；（6）自从安装以来程序运行的次数；（7）自从安装以来程序失效的次数；（8）程序变动的层次和标识；（9）因程序变动而增加的源语句数；（10）因程序变动而删除的源语句数；（11）每个改动耗费的人时数；（12）程序改动的日期；（13）软件工程师的名字；（14）维护要求表的标识；（15）维护类型；（l6）维护开始和完成的日期；（17）累计用于维护的人时数；（18）与完成的维护相联系的纯效益。8.3软件维护过程5.评价维护活动从下述七个方面度量维护工作：（1）每次程序运行平均失效的次数；（2）用于每一类维护活动的总人时数；（3）平均每个程序、每种语言、每种维护类型所做的程序变动效；（4）维护过程中增加或删除一个源语句平均花费的人时数；（5）维护每种语言平均花费的人时数；（6）一张维护要求表的平均周转时间；（7）不同维护类型所占的百分比。8.4程序修改的步骤及修改的副作用在软件维护时，必然会对源程序进行修改。通常对源程序的修改不能无计划地仓促上阵，为了正确、有效地修改,需要经历以下三个步骤。分析和理解程序修改程序重新验证程序分析和理解程序经过分析，全面、准确、迅速地理解程序是决定维护成败和质量好坏的关键。在这方面，软件的可理解性和文档的质量非常重要。修改程序对程序的修改，必须事先做出计划，有预谋地、周密有效地实施修改。1.设计程序的修改计划程序的修改计划要考虑人员和资源的安排。小的修改可以不需要详细的计划，而对于需要耗时数月的修改，就需要计划立案。2.修改代码，以适应变化在修改时，要求：(1)正确、有效地编写修改代码；(2)要谨慎地修改程序，尽量保持程序的风格及格式，要在程序清单上注明改动的指令；(3)不要删除程序语句，除非完全肯定它是无用的；(4)不要试图共用程序中已有的临时变量或工作区，为了避免冲突或混淆用途，应设置自己的变量；(5)插入错误检测语句；(6)在修改过程中做好修改的详细记录，消除变更中任何有害的副作用（波动效应）；3.修改程序的副作用所谓副作用是指因修改软件而造成的错误或其它不希望发生的情况。副作用有三种：修改代码的副作用、修改数据的副作用、文档的副作用。在修改源代码时，都可能引入错误。例如，删除或修改一个子程序、删除或修改一个标号、删除或修改一个标识符、改变程序代码的时序关系、改变占用存储的大小、改变逻辑运算符、修改文件的打开或关闭、改进程序的执行效率，以及把设计上的改变翻译成代码的改变时，都容易引入错误。(1)修改代码的副作用(2)修改数据的副作用在修改数据结构时，有可能造成软件设计与数据结构不匹配，因而导致软件出错。数据副作用就是修改软件信息结构导致的结果。容易导致设计与数据不相容的错误可以有：重新定义局部的或全局的常量重新定义记录或文件的格式增大或减小一个数组或高层数据结构的大小修改全局或公共数据重新初始化控制标志或指针重新排列输入／输出或子程序的参数(3)文档的副作用对数据流、软件结构、模块逻辑或任何其它有关特性进行修改时，必须对相关技术文档进行相应修改。否则会导致文档与程序功能不匹配，缺省条件改变，新错误信息不正确等错误。使得软件文档不能反映软件的当前状态。对于用户来说，软件事实上就是文档。如果对可执行软件的修改不反映在文档里，就会产生文档的副作用。对交互输入的顺序或格式进行修改，如果没有正确地记入文档中，就可能引起重大的问题。过时的文档内容、索引和文