软件工程 教学课件 PPT 作者 郑人杰 马素霞 麻志毅 第12章 软件维护

《软件工程 教学课件 PPT 作者 郑人杰 马素霞 麻志毅 第12章 软件维护》由会员分享，可在线阅读，更多相关《软件工程 教学课件 PPT 作者 郑人杰 马素霞 麻志毅 第12章 软件维护（55页珍藏版）》请在金锄头文库上搜索。

1、第5部分 软件维护与软件管理,第12章 软件维护,12.1 软件维护的概念,软件维护的定义 软件维护是指在软件运行/维护阶段对软件产品所进行的修 改就是所谓的维护。根据维护工作的性质，软件维护的活动 可以分为以下4种类型。 1改正性维护 改正性维护（corrective maintenance）为了识别和纠正 软件错误、改正软件性能上的缺陷、排除实施中的误使 用，应进行的诊断和改正错误的过程。例如，改正性维护 可以是改正原来程序中开关使用的错误；解决开发时未能 测试各种可能情况带来的问题等。,2适应性维护 随着信息技术的飞速发展，软件运行的外部环境（新的 硬、软件配置）或数据环境（数据库、数据

2、格式、数据输入 /输出方式、数据存储介质）可能发生变化，为了使软件适 应这种变化，而修改软件的过程叫做适应性维护（adaptive maintenance）。例如，需要对已运行的软件进行改造，以 适应网络环境或已升级改版的操作系统要求。 3完善性维护 为了满足新的功能与性能要求，需要修改或再开发软件， 以扩充软件功能、增强软件性能、改进加工效率、提高软件,12.1 软件维护的概念,的可维护性。这种情况下进行的维护活动叫做完善性维护 （perfective maintenance）。例如，完善性维护可能是修 改一个计算工资的程序，使其增加新的扣除项目；缩短系统 的应答时间，使其达到特定的要求等。

3、 4预防性维护 预防性维护（preventive maintenance）是指把今天的 方法学用于昨天的系统以满足明天的需要。也就是说，采 用先进的软件工程方法对需要维护的软件或软件中的某一部 分（重新）进行设计、编码和测试。,12.1 软件维护的概念,以上介绍的几类维护占总维护工作量的比例以及维护在 软件生存期成本所占比例如下图所示。,在整个软件维护阶段花费的全部工作量中，预防性维护 只占很小的比例，而完善性维护占了几乎一半的工作量。 软件维护活动花费的工作量占整个生存期工作量的70%以,12.1 软件维护的概念,上（工作量的比例直接反映了成本的比例） ，这是由于在 漫长的软件运行过程中需要

4、不断对软件进行修改，以使其 进一步完善、改正新发现的错误、适应新的环境和用户新 的需求，这些修改需要花费很多精力和时间，而且有时修 改不正确，还会引入新的错误。同时，软件维护技术不像 开发技术那样成熟、规范化，自然消耗工作量就比较多。,12.1 软件维护的概念,在软件维护中，影响维护工作量的因素主要有以下6种: （1）系统规模。 （2）程序设计语言。 （3）系统年龄大小。 （4）数据库技术的应用水平。 （5）所采用的软件开发技术及软件开发工程化的程度。 （6）其他：如应用的类型、数学模型、任务的难度、IF嵌 套深度、索引或下标数等，对维护工作量都有影响。,影响维护工作量的因素,12.1 软件维

5、护的概念,根据影响软件维护工作量的各种因素，针对3种典型维 护，James Martin等提出了一些策略，以控制维护成本。 1改正性维护 应用一些诸如数据库管理系统、软件开发环境、程序自 动生成系统和高级（第四代）语言等新技术可大大提高可 靠性，并减少进行改正性维护的需要。此外，还可考虑利 用应用软件包、防错性程序设计、通过周期性维护审查等 策略。,软件维护的策略,12.1 软件维护的概念,2适应性维护 这一类的维护不可避免，但可以采用以下策略加以控制。 （1）在配置管理时，把硬件、操作系统和其他相关环境因 素的可能变化考虑在内，可以减少某些适应性维护的工作 量。 （2）把与硬件、操作系统，以

6、及其他外围设备有关的程序 归到特定的程序模块中。可把因环境变化而必须修改的程序 局部于某些程序模块之中。 （3）使用内部程序列表、外部文件，以及处理的例行程序 包，可为维护时修改程序提供方便。,12.1 软件维护的概念,（4）使用面向对象技术，增强软件系统的稳定性，易于修 改和移植。 3完善性维护 利用前两类维护中列举的方法，也可以减少这一类维 护。特别是数据库管理系统、程序生成器、应用软件包， 可减少系统或程序员的维护工作量。 此外，建立软件系统的原型，把它在实际系统开发之前 提供给用户。用户通过研究原型，进一步完善他们的功能 要求，可以减少以后完善性维护的需要。,12.1 软件维护的概念,

7、为了有效地进行软件维护，应事先就开始做组织工作，确定实施维护的机构，明确提出维护申请报告的过程及评价的过程；为每一个维护申请规定标准的处理步骤；还必须建立维护活动的记录制度以及规定评价和评审的标准。,12.2 软件维护活动,软件维护申请报告,所有软件维护申请应按规定的方式提出。软件维护组织通常提供维护申请报告（maintenance request form，MRF），或称软件问题报告，由申请维护的用户填写。如果遇到一个错误，用户必须完整地说明产生错误的情况，包括输入数据、错误清单以及其他有关材料。如果申请的是适应性维护或完善性维护，用户必须提出一份修改说明,书，列出所有希望的修改。维护申请报

8、告将由维护管理员和 系统监督员来研究处理。 维护申请报告是由软件组织外部提交的文档，它是计划维 护工作的基础。软件组织内部应相应地做出软件修改报告 （software change report，SCR），指明： 所需修改变动的性质； 申请修改的优先级； 为满足某个维护申请报告，所需的工作量； 预计修改后的状况。 软件修改报告应提交修改负责人，经批准后才能开始进一 步安排维护工作。,12.2 软件维护活动,软件维护工作流程如下图所示。,12.2 软件维护活动,软件维护工作流程,第一步是先确认维护要求，然后由维护组织管理员确认 维护类型。对于改正性维护申请，如果存在严重的错误， 则必须安排人员，

9、在系统监督员的指导下，进行问题分 析，寻找错误发生的原因，进行“救火”性的紧急维护；对 于不严重的错误，可根据任务和人员情况，视轻重缓急进 行排队，统一安排时间。所谓“救火”式的紧急维护，是指 对非常严重的错误进行紧急修改，暂不再顾及正常的维护 控制，不必考虑评价可能发生的副作用。在维护完成、交 付用户之后再去做这些工作。,12.2 软件维护活动,对于适应性维护和完善性维护申请，需要先确定每项申请 的优先次序。若某项申请的优先级非常高，就可立即开始维 护工作；否则，维护申请和其他的开发工作一样，进行排 队，统一安排时间。 尽管维护申请的类型不同，但都要进行同样的技术工作。 这些工作包括：修改软

10、件需求说明、修改软件设计、设计评 审、对源程序做必要的修改、单元测试、集成测试（回归测 试）、确认测试、软件配置评审等。 在每次软件维护任务完成后，最好进行一次情况评审，对 以下问题做一总结：,12.2 软件维护活动,在目前情况下，设计、编码、测试中的哪一方面可以改 进？ 哪些维护资源应该有，但没有？ 工作中主要的或次要的障碍是什么？ 从维护申请的类型来看是否应当有预防性维护？情况评 审对将来的维护工作如何进行会产生重要的影响，并可 为软件机构的有效管理提供重要的反馈信息。,12.2 软件维护活动,12.2 软件维护活动,维护档案记录,为了估计软件维护的有效程度，确定软件产品的质量，同时确定维

11、护的实际开销，需要在维护的过程中做好维护档案记录。其内容包括程序名称、源程序语句条数、机器代码指令条数、所用的程序设计语言、程序安装的日期、程序安装后的运行次数、与程序安装后运行次数有关的处理故障次数、程序改变的层次及名称、修改程序所增加的源程序语句条数、修改程序所减少的源程序语句条数、每次修改所付出的“人时”数、修改程序的日期、软件维护人员的姓名、维护申请报告的名称、维护类型、维护开始时间和维护结束时间、花费在维护上的累计“人时”数、维护工作的净收益等。对每项维护任务都应该收集上述数据。,评价维护活动可参考的度量值有： 每次程序运行时的平均出错次数； 花费在每类维护上的总“人时”数； 每个程

12、序、每种语言、每种维护类型的程序平均修改次 数； 因为维护，增加或删除每个源程序语句所花费的平均“人 时”数； 用于每种语言的平均“人时”数； 维护申请报告的平均处理时间； 各类维护申请的百分比。,12.2 软件维护活动,维护评价,为了正确、有效地进行程序修改，需要经历3个步骤：分 析和理解程序、实施修改以及重新验证程序。,12.3 程序修改的步骤及修改的副作用,分析和理解程序 经过分析，全面、准确、迅速地理解程序是决定维护成 败和质量好坏的关键。在这方面，软件的可理解性和文档的 质量非常重要。为此必须： （1）研究程序的使用环境及有关资料，尽可能得到更多的 背景信息； （2）理解程序的功能和

13、目标；,（3）掌握程序的结构信息，即从程序中细分出若干结构成 分，如程序系统结构、控制结构、数据结构和输入/输 出结构等； （4）了解数据流信息，即所涉及的数据来自何处，在哪里 被使用； （5）了解控制流信息，即执行每条路径的结果； （6）如果设计存在，则可利用它们来帮助画出结构图和高 层流程图； （7）理解程序的操作（使用）要求。,12.3 程序修改的步骤及修改的副作用,为了容易地理解程序，要求自顶向下地理解现有源程序的 程序结构和数据结构，为此可采用如下几种方法。 （1）分析程序结构图。 （2）数据跟踪。 （3）控制跟踪。可采用符号执行或实际动态跟踪的方法， 了解数据是如何从一个输入源到达

14、输出点的。 （4）在分析的过程中，应充分阅读和使用源程序清单和文 档，分析现有文档的合理性。 （5）充分使用由编译程序或汇编程序提供的交叉引用表、 符号表，以及其他有用的信息。 （6）如有可能，争取参加开发工作。,12.3 程序修改的步骤及修改的副作用,对程序的修改，必须事先做出计划，有准备地、周密有效 地实施修改。 1设计程序的修改计划 程序的修改计划要考虑人员和资源的安排。修改计划的内 容主要包括以下几项： （1）规格说明信息：数据修改、处理修改、作业控制语言 修改、系统之间接口的修改等。 （2）维护资源：新程序版本、测试数据、所需的软件系 统、计算机时间等。,12.3 程序修改的步骤及修

15、改的副作用,修改程序,（3）人员：程序员、用户相关人员、技术支持人员、厂家 联系人、数据录入员等。 （4）提供：纸质、计算机媒体等。 针对以上每一项，要说明必要性、从何处着手、是否接 受、日期等。通常，可采用自顶向下的方法，在理解程序的 基础上做如下工作： （1）研究程序的各个模块、模块的接口及数据库，从全局 的观点提出修改计划。 （2）依次把要修改的、以及那些受修改影响的模块和数据 结构分离出来。,12.3 程序修改的步骤及修改的副作用,（3）详细地分析要修改的，以及那些受变更影响的模块和 数据结构的内部细节，设计修改计划，标明新逻辑及 要改动的现有逻辑。 （4）向用户提供回避措施。用户的某

16、些业务因软件中发生 问题而中断，为不让系统长时间停止运行，需把问题 局部化，在可能的范围内继续开展业务。 2修改代码，以适应变化 修改时，要求： （1）正确、有效地编写修改代码； （2）要谨慎地修改程序，尽量保持程序的风格及格式，要,12.3 程序修改的步骤及修改的副作用,在程序清单上注明改动的指令； （3）不要匆忙删除程序语句，除非完全肯定它是无用的； （4）不要试图共用程序中已有的临时变量或工作区，为了 避免冲突或混淆用途，应自行设置自己的变量； （5）插入错误检测语句； （6）保持详细的维护活动和维护结果记录； （7）如果程序结构混乱，修改受到干扰，可抛弃程序重新 编写。,12.3 程序修改的步骤及修改的副作用,所谓程序修改的副作用是指因修改软件而造成的错误 或其他不希望发生的情况，有以下3种副作用： 1修改代码的副作用 在使用程序设计语言修改源代码时，都可能引入新的 错误。例如，删除或修改一个子程序、删除或修改一个标 号、删除或修改一个标识符、改变程序代码的时序关系、 改变占用存储的大小、改变逻辑