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