《软件工程维护》PPT课件.ppt

《《软件工程维护》PPT课件.ppt》由会员分享，可在线阅读，更多相关《《软件工程维护》PPT课件.ppt（56页珍藏版）》请在三一办公上搜索。

1、,软件工程第八章 维护,第八章 维护,8.1 软件维护的定义8.2 软件维护的特点8.3 软件维护过程8.4 软件的可维护性（自学）8.5 提高可维护性的方法（补充自学）8.6 预防性维护（自学）8.7 软件再工程过程（自学）,8.1 软件维护的定义,在软件产品被开发出来并交付用户使用之后，就进入了软件的运行维护阶段：这个阶段是软件生命周期的最后一个阶段，其基本任务是保证软件在一个相当长的时期能够正常运行。软件维护需要的工作量非常大，平均说来，大型软件的维护成本高达开发的4倍左右。目前国外许多软件开发组织把60%以上的人力用于维护已有的软件，而且随着软件产品数量增多和使用寿命延长，这个百分比还

2、在持续上升。软件工程的主要目标就是提高软件的可维护性，减少软件维护所需要的工作量，降低软件系统的总成本。,1.软件维护的定义：在软件运行维护阶段对软件产品进行的修改就是所谓的维护。2.改正性维护：在软件交付使用后，因开发时测试的不彻底、不完全，必然会有部分隐藏的错误遗留到运行阶段。这些隐藏下来的错误在某些特定的使用环境下就会暴露出来。为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用，应当进行的诊断和改正错误的过程就叫做改正性维护。3.适应性维护：在使用过程中，外部环境（新的硬、软件配置）和数据环境（数据库、数据格式、数据输入/输出方式、数据存储介质）可能发生变化。为使软件适应这

3、种变化，而去修改软件的过程。,8.1 软件维护的定义,4.完善性维护：软件的使用过程中，用户往往会对软件提出新的功能与性能要求。进而需要修改或再开发软件，以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性的维护活动实践表明，完善性维护所占的比重最大。即大部分维护工作是改变和加强软件，而不是纠错。完善性维护占了几乎一半的工作量。完善性维护不一定是救火式的紧急维修，而可以是有计划、有预谋的一种再开发活动。事实证明，来自用户要求扩充、加强软件功能、性能的维护活动约占整个维护工作的50。5.预防性维护：采用先进的软件工程方法对需要维护的软件或软件中的某一部分（重新）进行设计、编制和测试。是

4、为了提高软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础。,8.1 软件维护的定义,软件维护活动所花费的工作占整个生存期工作量的70%以上，这是由于在漫长的软件运行过程中需要不断对软件进行修改，以改正新发现的错误、适应新的环境和用户新的要求，这些修改需要花费很多精力和时间，而且有时会引入新的错误。,8.1 软件维护的定义,1.影响维护工作量的因素在软件的维护过程中，需要花费大量的工作量，从而直接影响了软件维护的成本。系统大小：系统越大，理解掌握起来越困难，所执行功能越复杂。因而需要更多的维护工作量。程序设计语言：语言的功能越强，程序的模块化和结构化程度越高，程序的可读性越好。系统年龄

5、：数据库技术的应用程度先进的软件开发技术其它：应用的类型、数学模型、任务的难度、开关与标记、IF嵌套深度、索引或下标数等对维护工作量都有影响。,8.2 软件维护的特点,2.结构化维护与非结构化维护差别巨大非结构化维护的代价很高（浪费精力并且遭受挫折），这种维护方式是没有使用软件工程方法学出来的软件的必然结果。以完整的软件配置为基础的结构化维护，是在软件开发过程中应用软件过程方法学的结果。虽然有了软件的完整配置并不能保证维护时没有问题，但是确实能减少精力的浪费并且可以提高维护的总体质量在过去的几十年中，软件维护的费用稳步上升。1970年用于维护已有软件的费用只占软件总预算的35%40%，1980

6、年上升为40%60%，1990年上升为70%80%。,8.2 软件维护的特点,3、维护成本(维护的代价高昂)有形的软件维护成本是花费了多少钱，无形的维护成本有更大的影响。不能及时安排，使得客户不满意；变更的结果引入新的故障，使软件整体质量下降 把软件人员抽调到维护工作中，干扰了软件开发软件维护的代价是降低了生产率，在做老程序的维护时非常明显。例如，开发每一行源代码耗资25美元，维护每一行源代码需要耗资1000美元。维护工作量包括生产性活动（如分析和评价、设计修改和实现）和“轮转”活动（如力图理解代码在做什么、试图判明数据结构、接口特性、性能界限等）。,8.2 软件维护的特点,维护工作量的模型M

7、是维护中消耗的总工作量p是上面描述的生产性工作量K是一个经验常数c是因缺乏好的设计和文档而导致复杂性的度量d是对软件熟悉程度的度量。模型指明，如果使用了不好的软件开发方法（未按软件工程要求做），原来参加开发的人员或小组不能参加维护，则工作量（及成本）将按指数级增加。,8.2 软件维护的特点,4.维护的问题很多与软件维护有关的绝大部分问题，都可归因于软件开发的方法有缺点。在软件生命周期的头两个时期没有严格而又科学的管理和规划，几乎必然会导致在最后阶段出现问题。和软件维护有关的部分问题：理解别人写的程序通常非常困难，而且困难程度随着配置成分的减少而迅速增加。如果仅有程序代码没有文档，则会出现严重的

8、问题需要维护的软件往往没有合格的文档，或者文档资料显著不足。认识到软件必须有文档仅仅是第一步，容易理解的并且和程序代码完全一致的文档才真正有价值。,8.2 软件维护的特点,当要求对软件进行维护时，不能指望由开发人员给我们仔细说明软件。由于维护阶段持续的时间很长，因此，当需要理解软件时，往往原来写程序的人已经不在附近了。绝大多数软件在设计时没有考虑将来的修改。除非是强调模块独立原理的设计方法学，否则修改软件既困难又容易发生差错。软件维护不是一项吸引人的工作。形成这种观念很发程度上是因为维护工作经常遭受挫折。上述种种问题在现有的没采用软件过程思想开发出来的软件中，都或多或少地存在着。,8.2 软件

9、维护的特点,维护过程本质上是修改和压缩了的软件定义和开发过程为了有效地进行软件维护，应事先就开始做组织工作。首先建立维护的机构 申明提出维护申请报告的过程及评价的过程 为每一个维护申请规定标准的处理步骤 建立维护活动登记制度及规定评价和评审的标准1、维护组织除了较大的软件开发公司外，通常在软件维护工作方面，并不保持一个正式的组织机构。虽然不要求建立一个正式的维护机构，但是在开发部门确立一个非正式的维护机构则是非常必要的。维护申请提交给维护管理员，他把申请交给某个系统监督员去评价。一旦做出评价，由修改负责人确定如何进行修改。,8.3 软件维护过程,软件维护的机构,8.3 软件维护过程,软件维护的

10、机构,8.3 软件维护过程,在修改程序的过程中，由配置管理员严格把关，控制修改的范围，对软件配置进行审计。在维护之前把责任明确，可以减少维护过程中的混乱2、软件维护申请报告（软件问题报告）维护申请报告，由申请维护的用户填写。用户必须完整地说明产生错误的情况，包括输入数据、错误清单以及其它有关材料。如果申请的是适应性维护或完善性维护，用户必须提出一份修改说明书，列出所有希望的修改。申请报告将由维护管理员和系统监督员来研究处理。他们应相应地做出软件修改报告，指明：所需修改变动的性质；申请修改的优先级；为满足某个维护申请报告，所需的工作量；预计修改后的状况。修改报告提交修改负责人批准后才能开始进一步

11、安排维护工作。,8.3 软件维护过程,软件维护工作流程,尽管维护申请类型不同，但都要进行同样的技术工作 修改软件需求说明 修改软件设计 设计评审 对源程序做必要的修改 单元测试 集成测试(回归测试)确认测试 软件配置评审等。在每次软件维护任务完成后进行情况评审，对以下问题做一总结：(1)在目前情况下，设计、编码、测试中的哪一方面可以改进?(2)哪些维护资源应该有但没有?(3)工作中主要的或次要的障碍是什么?(4)从维护申请的类型来看是否应当有预防性维护?情况评审对将来的维护工作如何进行会产生重要的影响。,8.3 软件维护过程,3、维护档案记录程序名称 源程序语句条数机器代码指令条 数所用的程序

12、设计语言程序安装的日期 程序安装后的运行次数与程序安装后运行次数有关的处理故障次数程序改变的层次及名称修改程序增加的源程序语句条数修改程序减少的源程序语句条数每次修改所付出的“人时”数修改程序的日期 软件维护人员的姓名维护申请报告的名称、维护类型维护开始时间和维护结束时间、花费在维护上的累计“人时”数维护工作的净收益等。,8.3 软件维护过程,4、维护评价评价维护活动比较困难，因为缺乏可靠的数据。如果维护的档案记录做得比较好，可以得出一些维护“性能”方面的度量值。每次程序运行时的平均出错次数；花费在每类维护上的总“人时”数；每个程序、每种语言、每种维护类型的程序平均修改次数；因为维护，增加或删

13、除每个源程序语句所花费的平均“人时”数；用于每种语言的平均“人时”数；维护申请报告的平均处理时间；各类维护申请的百分比。据此可对开发技术、语言选择、维护工作计划、资源分配、以及其它许多方面做出判定。,8.3 软件维护过程,许多软件的维护十分困难，原因在于这些软件的文档不全、质量差、开发过程不注意采用好的方法，忽视程序设计风格等。许多维护要求并不是因为程序中出错而提出的，而是为适应环境变化或需求变化而提出的。为了使得软件能够易于维护，必须考虑使软件具有可维护性。1、软件可维护性的定义软件可维护性是指纠正软件系统出现的错误和缺陷，以及为满足新的要求进行修改、扩充或压缩的容易程度。维护人员理解、改正

14、、改动或改进这个软件的难易程度。提高可维护性是支配软件工程方法学所有步骤的关键目标。,8.4 软件可维护性,可维护性、可使用性、可靠性是衡量软件质量的主要质量特性，也是用户十分关心的几个方面。软件的可维护性是软件开发阶段各个时期的关键目标。目前广泛使用的是用如下的七个特性来衡量程序的可维护性。可理解性、可使用性、可测试性、可移植性、可修改性、效率、可靠性而且对于不同类型的维护，这七种特性的侧重点也不相同。这些质量特性通常体现在软件产品的许多方面;为使每一个质量特性都达到预定的要求，需要在软件开发的各个阶段采取相应的措施加以保证。这些质量要求要渗透到而各开发阶段的各个步骤当中。因此，软件的可维护

15、性是产品投入运行以前各阶段面向上述各质量特性要求进行开发的最终结果。,8.4 软件可维护性,在各类维护中的侧重点,8.4 软件可维护性,2、可维护性的度量人们一直期望对软件的可维护性做出定量度量，但要做到这一点并不容易。常用的度量一个可维护的程序的七种特性的方法。就是质量检查表、质量测试、质量标准质量检查表是用于测试程序中某些质量特性是否存在的一个问题清单。评价者针对检查表上的每一个问题，依据自己的定性判断，回答“Yes”或者“No”。质量测试与质量标准则用于定量分析和评价程序的质量。由于许多质量特性是相互抵触的，要考虑几种不同的度量标准，相应地去度量不同的质量特性。,8.4 软件可维护性,2

16、.1.可理解性可理解性表明人们通过阅读源代码和相关文档，了解程序功能及其如何运行的容易程度。一个可理解的程序应具备以下一些特性：模块化，风格一致性，不使用令人捉摸不定或含糊不清的代码，使用有意义的数据名和过程名，结构化，完整性等。2.2.可靠性可靠性表明一个程序按照用户的要求和设计目标，在给定的一段时间内正确执行的概率。关于可靠性，度量的标准主要有：平均失效间隔时间MTTF 平均修复时间MTTR 有效性A=MTBD/(MTBD+MDT),8.4 软件可维护性,度量可靠性的方法 根据程序错误统计数字，进行可靠性预测。常用方法是利用一些可靠性模型，根据程序测试时发现并排除的错误数预测平均失效间隔时

17、间MTTF。根据程序复杂性，预测软件可靠性。用程序复杂性预测可靠性，前提条件是可靠性与复杂性有关。因此可用复杂性预测出错率。程序复杂性度量标准可用于预测哪些模块最可能发生错误，以及可能出现的错误类型。2.3.可测试性可测试性表明论证程序正确性的容易程度。程序越简单，证明其正确性就越容易。而且设计合用的测试用例，取决于对程序的全面理解。一个可测试的程序应当是可理解的，可靠的，简单的。,8.4 软件可维护性,用于可测试性度量的检查项目如下：程序是否模块化?结构是否良好?程序是否可理解?程序是否可靠?程序是否能显示任意中间结果?程序是否能以清楚的方式描述它的输出?程序是否能及时地按照要求显示所有的输

18、入?程序是否有跟踪及显示逻辑控制流程的能力?程序是否能从检查点再启动?程序是否能显示带说明的错误信息?2.4.可修改性可修改性表明程序容易修改的程度。一个可修改的程序应当是可理解的、通用的、灵活的、简单的。,8.4 软件可维护性,通用性是指程序适用于各种功能变化而无需修改。灵活性是指能够容易地对程序进行修改。测试可修改性的一种定量方法是修改练习。其基本思想是通过做几个简单的修改，来评价修改的难度。设C是程序中各个模块的平均复杂性，n是必须修改的模块数，A 是要修改的模块的平均复杂性。则修改的难度D由下式计算：D=A/C2.5.可移植性可移植性表明程序转移到一个新的计算环境的可能性的大小。或者它

19、表明程序可以容易地、有效地在各种各样的计算环境中运行的容易程度。一个可移植的程序应具有结构良好、灵活、不依赖于某一具体计算机或操作系统的性能。,8.4 软件可维护性,用于可移植性度量的检查项目如下：是否是用高级的独立于机器的语言来编写程序?是否使用广泛使用的标准化的程序设计语言来编写程序?是否仅使用了这种语言的标准版本和特性?程序中是否使用了标准的普遍使用的库功能和子程序?程序中是否极少使用或根本不使用操作系统的功能?程序在执行之前是否初始化内存?程序在执行之前是否测定当前的输入输出设备?程序是否把与机器相关的语句分离了出来，集中放在了一些单独的程序模块中，并有说明文件?程序是否结构化?并允许

20、在小一些的计算机上分段(覆盖)运行?程序中是否避免了依赖于字母数字或特殊字符的内部位表示?,8.4 软件可维护性,2.6.效率效率表明一个程序能执行预定功能而又不浪费机器资源的程度。这些机器资源包括内存容量、外存容量、通道容量和执行时间。用于效率度量的检查项目如下：程序是否模块化?结构是否良好?是否消除了无用的标号与表达式，以充分发挥编译器优化作用?程序的编译器是否有优化功能?是否把特殊子程序和错误处理子程序都归入了单独的模块中?是否以快速的数学运算代替了较慢的数学运算?,8.4 软件可维护性,是否尽可能地使用了整数运算，而不是实数运算?是否在表达式中避免了混合数据类型的使用，消除了不必要的类

21、型转换?程序是否避免了非标准的函数或子程序的调用?在几条分支结构中，是否最有可能为“真”的分支首先得到测试?在复杂的逻辑条件中，是否最有可能为“真“的表达式首先得到测试?2.7.可使用性从用户观点出发，可使用性定义为程序方便、实用、及易于使用的程度。一个可使用的程序应是易于使用的、能允许用户出错和改变，并尽可能不使用户陷入混乱状态的程序。,8.4 软件可维护性,用于可使用性度量的检查项目如下：程序是否具有自描述性?程序是否能始终如一地按照用户的要求运行?程序是否让用户对数据处理有一个满意的和适当的控制?程序是否容易学会使用?程序是否使用数据管理系统来自动地处理事务性工作和管理格式化、地址分配及

22、存储器组织。程序是否具有容错性?程序是否灵活?,8.4 软件可维护性,2.8 其它间接定量度量可维护性的方法问题识别的时间；因管理活动拖延的时间；收集维护工具的时间；分析、诊断问题的时间；修改规格说明的时间；具体的改错或修改的时间；局部测试的时间；集成或回归测试的时间；维护的评审时间；这些数据反映了维护全过程中检错纠错验证的周期，即从检测出软件存在的问题开始至修正它们并经回归测试验证这段时间。可以粗略地认为，这个周期越短，维护越容易。,8.4 软件可维护性,建立明确的软件质量目标和优先级使用提高软件质量的技术和工具进行明确的质量保证审查选择可维护的程序设计语言改进程序的文档,8.5 提高可维护

23、性的方法,1、建立明确的软件质量目标和优先级一个可维护的程序应是可理解的、可靠的、可测试的、可修改的、可移植的、效率高的、可使用的。要实现这所有的目标，需要付出很大的代价，而且也不一定行得通。某些质量特性是相互促进的，例如可理解性和可测试性、可理解性和可修改性。另一些质量特性是相互抵触的，如效率和可移植性、效率和可修改性等。每一种质量特性的相对重要性应随程序的用途及计算环境的不同而不同。例如，对编译程序来说，可能强调效率；但对管理信息系统来说，则可能强调可使用性和可修改性。应当对程序的质量特性，在提出目标的同时还必须规定它们的优先级。,8.5 提高可维护性的方法,2、使用提高软件质量的技术和工

24、具模块化 如果需要改变某个模块的功能，则只要改变这个模块，对其它模块影响很小；如果需要增加程序的某些功能，则仅需增加完成这些功能的新的模块或模块层；程序的测试与重复测试比较容易；程序错误易于定位和纠正；结构化程序设计 程序被划分成分层的模块结构；模块调用控制必须从模块入口点进入，从其出口点退出。模块的控制结构仅限于顺序、选择、重复三种，且没有GOTO语句。每个程序变量只用于唯一的程序目的，而且变量的作用范围应是明确的、有限制的。,8.5 提高可维护性的方法,使用结构化程序设计技术，提高现有系统的可维护性 采用备用件的方法用一个新的结构良好的模块替换掉整个要修改的模块。采用自动重建结构和重新格式

25、化的工具(结构更新技术)把非结构化代码转换成良好结构代码。改进现有程序的不完善的文档 建立或补充系统说明书、设计文档、模块说明书、以及在源程序中插入必要的注释。3、进行明确的质量保证审查质量保证审查对于获得和维持软件的质量，是一个很有用的技术。审查用来检测在开发和维护阶段内发生的质量变化。一旦检测出问题，就可以采取措施来纠正，以控制不断增长的软件维护成本，延长软件系统的有效生命期。,8.5 提高可维护性的方法,3.1.在检查点进行复审保证软件质量的最佳方法是在软件开发的最初阶段把质量要求考虑进去，并在开发过程每一阶段的终点，设置检查点进行检查。检查的目的是要证实，已开发的软件是否符合标准，是否

26、满足规定的质量需求。在不同的检查点，检查的重点不完全相同。在设计阶段，检查重点是可理解性、可修改性、可测试性。可理解性检查的重点是程序的复杂性。对每个模块可用McCabe环路来计算模块的复杂性，若大于10，则需重新设计。可以使用各种质量特性检查表，或用度量标准来检查可维护性。审查小组可以采用人工测试一类的方式，进行审查。,8.5 提高可维护性的方法,软件开发期间各个检查点的检查重点,8.5 提高可维护性的方法,3.2.验收检查验收检查是一个特殊的检查点的检查，是交付使用前的最后一次检查验收检查实际上是验收测试的一部分，只不过它是从维护的角度提出验收的条件和标准。验收检查必须遵循的最小验收标准。

27、(1)需求和规范标准 需求应当以可测试的术语进行书写，排列优先次序和定义；区分必须的、任选的、将来的需求；包括对系统运行时的计算机设备的需求；对维护、测试、操作、以及维护人员的需求；对测试工具等的需求。,8.5 提高可维护性的方法,(2)设计标准 程序应设计成分层的模块结构。每个模块应完成唯一的功能，并达到高内聚、低耦合；通过一些知道预期变化的实例，说明设计的可扩充性、可缩减性和可适应性。(3)源代码标准 尽可能使用最高级的程序设计语言，且只使用语言的标准版本；所有的代码都必须具有良好的结构；所有的代码都必须文档化，在注释中说明它的输入、输出、以及便于测试再测试的一些特点与风格。(4)文档标准

28、文档中应说明：程序的输入输出、使用的方法算法、错误恢复方法、所有参数的范围、缺省条件等。,8.5 提高可维护性的方法,3.3.周期性地维护审查检查点复查和验收检查，可用来保证新软件系统的可维护性。对已有的软件系统，则应当进行周期性的维护检查。软件在运行期间进行修改，会导致软件质量有变坏的危险，破坏程序概念的完整性。必须定期检查，对软件做周期性的维护审查，以跟踪软件质量的变化。周期性维护审查实际上是开发阶段检查点复查的继续，并且采用的检查方法、检查内容都是相同的。维护审查的结果可以同以前的维护审查的结果，以前的验收检查的结果、检查点检查的结果相比较，任何一种改变都表明在软件质量上或其它类型的问题

29、上可能起了变化。对于改变的原因应当进行分析。,8.5 提高可维护性的方法,3.4.对软件包进行检查软件包是一种标准化的，可为不同单位、不同用户使用的软件。一般源代码和程序文档不会提供给用户。对软件包的维护采取以下方法。使用单位的维护人员首先要仔细分析、研究卖主提供的用户手册、操作手册、培训教程等，以及卖方提供的验收测试报告等。在此基础上，深入了解本单位的希望和要求，编制软件包的检验程序。检查软件包程序所执行的功能是否与用户的要求和条件相一致。为了建立这个程序，维护人员可利用卖方提供的验收测试实例，还可以自己重新设计新的测试实例 根据测试结果，检查和验证软件包的参数或控制结构，以完成软件包的维护

30、。,8.5 提高可维护性的方法,4、选择可维护的程序设计语言程序设计语言的选择，对程序的可维护性影响很大。机器语言 汇编语言,高级语言(FORTRANCOBOL等),查询语言 表生成语言 图象语言应用生成语言,8.5 提高可维护性的方法,5、改进程序的文档文档是影响软件可维护性的决定因素。由于长期使用的大型系统在使用过程中必然会受多次修改，所以文档比程序代码更重要程序文档是对程序总目标、程序各组成部分之间的关系、程序设计策略、程序实现过程的历史数据等的说明和补充。对于程序维护人员来说，要想按程序编制人员的意图重新改造程序，并对今后变化的可能性进行估计，缺了文档是不行的。因此，为了维护程序，人们

31、必须阅读和理解文档。另外，在软件维护阶段，利用历史文档，可以大大简化维护工作。通过了解原设计思想，可以判断出错之处，指导维护人员选择适当的方法修改代码而不危及系统的完整性。历史文档有：系统开发日志、错误记载、系统维护日志。,8.5 提高可维护性的方法,可以分为用户文档和系统文档两类：用户文档主要描述系统功能和使用方法，并不关心这些功能是怎样实现的系统文档描述系统设计、实现和测试等各方面的内容总的来说，软件文档应该满足下述要求：必须描述如何使用这个系统，没有这种描述即使是最简单的系统也无法使用必须描述怎样安装和管理这个系统必须描述系统需求和设计必须描述系统的实现和测试，以便使系统成为可维护的,8

32、.5 提高可维护性的方法,所谓预防性维护，就是为了提高未来的可维护性或可靠性，而主动地修改软件。预防性维护定义为：把今天的方法学应用到昨天的软件系统上，以支持明天的需求。初看起来，在一个正在工作的程序版本已经存在的情况下，重新开发这个大型程序似乎是一种浪费，但是，考虑到下述事实预防性维护实际上是可行的：(1)维护一行源代码的成本事实可能是该行代码初始开发成本的2040倍；(2)使用现代设计概念重新设计软件体系结构（程序结构和数据结构），对未来的维护工作将有很大帮助；(3)由于软件原型（即现在正在工作的程序）已经存在，软件开发生产率将远远高于平均水平；(4)现在用户已经有比较丰富的使用该软件的经

33、验，因此，很容易确定新的需求和变更方向；(5)利用软件再工程工具可以自动完成部分工作；(6)在完成预防性维护的过程中，可以建立起完整的软件配置（文档、程序和数据）。,8.6 预防性维护,预防性维护也为软件再工程。典型的软件再工程过程模型定义了6类活动。在某些情况下，这些活动按照图中所示次序以线性顺序进行，但也并非总是如此，例如，可能在文档重构之前需要先进行逆向工程，以理解程序的工作原理。,8.7 软件再工程过程,图示的软件在工程过程范型是一个循环模型这意味着作为该范形组成部分的每个活动都可能重复进行而且对于某个特定的循环来说，过程可以在完成任意一个活动之后终止。,1.库存目录分析对软件组织用语

34、的每个应用系统都进行预防性维护是不现实的，也是不必要的。一般说来，下述3类程序有可能成为预防性的对象：该程序将在今后数年内继续维护的对象当前正在成功地使用着该程序可能在最近的将来要对该程序做较大程度的修改或扩充应该仔细的、分析库存目录，按照业务重要程度、寿命、当前可维护性、预期的修改次数等标准，把库中的应用小排序，从中选出再工程的侯选者。然后合理地分配再工程所需要的资源。,8.7 软件再工程过程,2.文档重构老程序固有的特点缺乏文档，根据具体情况可采用下述3种方法之一来处理这个问题：1)如果一个程序是相对稳定的，正在走向生命的终点，而且可能不会再修改它，则不必为它建立文档。2)为了便于今后的维

35、护，必须更新文档，但是由于资源有限，应该采用“使用时建立文档”的方法，也就是说，不是一下子把某应用系统的文档全部都重建起来，而是只建立系统中当前正在修改的那些部分的完整文档。3)如果某应用系统是用户完成业务工作的关键，而且必须重构全部文档，则仍然应该尽量把文档工作减少到必需的最小量。,8.7 软件再工程过程,3.逆向工程软件的逆向工程是，分析程序以便在比源程序更高的抽象层次上创建出程序的某种描述的过程，也就是说，逆向工程是一个恢复设计结果的过程。4.代码重构某些老程序的体系结构比较合理，但是，一些模块的编码方式却是难于理解、测试和维护的。在这种情况下，可以重构这些模块的代码。通常，代码重构并不

36、修改程序的体系结构，它只关注个体模块的设计细节以及在模块中定义的局部数据结构。如果重构扩展到模块边界之外并涉及软件体系结构，则重构变成了正向工程。,8.7 软件再工程过程,5.数据重构对数据体系结构差的程序很难进行适应性和完善性维护，因此，数据体系结构比源代码对程序的长期生存力有更大的影响。数据重构是一种全范围的再工程活动。由于数据结构对程序体系结构及程序中的算法有很大影响，对数据的修改必然会导致程序体系结构或代码层的改变。6.正向工程：正向工程也称为更新或再造。正向工程过程应用现代软件工程的概念、原理、技术和方法，重新开发现有的某些应用系统。在大多数情况下，经过正向工程过程后的出的软件，不仅

37、重新实现了现有系统的功能，而且增加了新功能，提高了整体性能。,8.7 软件再工程过程,小结,软件维护的定义：在软件运行维护阶段对软件产品进行的修改就是所谓的维护。改正性维护：在软件交付使用后，为了识别和纠正由于软件开发时隐藏的错误、改正软件性能上的缺陷，软件进行的诊断和改正错误的过程就。适应性维护：在使用过程中，外部环境（新的硬、软件配置）和数据环境（数据库、数据格式、数据输入/输出方式、数据存储介质）发生变化。为使软件适应这种变化，而去修改软件的过程。完善性维护：软件的使用过程中，对用户对软件提出新的功能与性能要求。进而以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性的维护活动

38、预防性维护：为了提高软件的可维护性、可靠性等，采用先进的软件工程方法对需要维护的软件或软件中的某一部分（重新）进行设计、编制和测试。,某软件公司拟采取下述措施提高他们开发出的软件产品的可维护性。请判断哪些措施是正确的，哪些措施不正确。(1)在分析用户需求时同时考虑维护问题。(2)测试完程序后，删去程序中的注解以缩短源程序长度。(3)在软件开发过程中尽量保证各阶段文档的正确性。(4)编码时尽量多用全局变量。(5)选用时间效率和空间效率尽可能高的算法。(6)尽可能利用硬件特点以提高程序效率。(7)尽可能使用高级语言编写程序。(8)进行总体设计时加强模块间的联系。(9)尽量减少程序模块的规模。(10

39、)用数据库系统代替文件系统来存储需要长期保存的信息,软件工程中的一些观念讨论,(11)用CASE环境或程序自动生成工具来自动生成一部分程序。(12)尽量用可重用的软件构件来组装程序。(13)使用先进的软件开发技术。(14)采用防错程序设计技术，在程序中引入自检能力。(15)把与硬件及操作系统有关的代码放到某些特定的程序模块中。,软件工程中的一些观念讨论,1某些软件工程师不同意“目前国外许多软件开发组织把60%以上的人力用于维护已有的软件”的说法，他们争论说：“我并没有花费我的60%的时间去改正我所开发的程序中的错误”。请问，你对上述争论有何看法？2为什么大型软件的维护成本高达开发成本的4倍左右？3假设你的任务是对一个已有的软件做重大修改，而且只允许你从下述文档中选取两份：(a)程序的规格说明；(b)程序的详细设计结果（自然语言描述加上某种设计工具表示);（c)源程序清单（其中有适当数量的注解)。你将选取哪两份文档？为什么这样选取？4当一个十几年前开发出的程序还在为其用户完成关键的业务工作时，是否有必要对它进行再工程？如果对它进行再工程，经济上是否划算？5代码重构与正向工程有何相同之处？有何不同之处？,作业,