第 11 章软件维护

第11章软件维护 • 主要内容：软件维护的概念及种类；软件维护的特点；软件维护的实施过程与管理方法；软件的可维护性和提高软件可维护性的方法；软件维护的副作用。 • 本章重点：软件维护的概念及种类，软件维护的实施过程与管理方法。 • 本章难点：软件的可维护性及提高软件可维护性的方法。

第11章软件维护 • 11.1 软件维护的种类 • 11.2 软件维护的特点 • 11.3 软件维护的实施 • 11.4 软件的可维护性 • 11.5 软件维护的副作用

11.1 软件维护的种类 • 在软件运行／维护阶段对软件产品所进行的修改就是维护。要求进行维护的原因多有三种类型： • (1) 改正在特定的使用条件下暴露出来的一些潜在程序错误或设计缺陷； • (2) 因在软件使用过程中数据环境发生变化(例如一个事务处理代码发生改变)或处理环境发生变化(例如安装了新的硬件或操作系统)，需要修改软件以适应这种变化。 • (3) 用户和数据处理人员在使用时常提出改进现有功能，增加新的功能，以及改善总体性能的要求，为满足这些要求，就需要修改软件把这些要求纳入到软件之中。

11.1 软件维护的种类 • 1. 校正性维护(Corrective maintenance) • 为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用，应当进行的诊断和改正错误的过程，就叫做校正性维护。

11.1 软件维护的种类 • 2. 适应性维护(Adaptive maintenance) • 随着计算机的飞速发展，外部环境(新的硬、软件配置)或数据环境(数据库、数据格式、数据输入／输出方式、数据存储介质)可能发生变化，为了使软件适应这种变化，而去修改软件的过程就叫做适应性维护。 • 3. 完善性维护(Perfective maintenance) • 在软件的使用过程中，用户往往会对软件提出新的功能与性能要求。为了满足这些要求，需要修改或再开发软件，以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性。这种情况下，进行的维护活动叫做完善性维护。

11.1 软件维护的种类 • 4. 预防性维护(Preventive maintenance) • 除了以上三类维护之外，还有一类维护活动，叫做预防性维护。这是为了提高软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础。

11.1 软件维护的种类 • 注意: • 在维护阶段的最初一、二年，校正性维护的工作量较大。随着错误发现率急剧降低，并趋于稳定，就进入了正常使用期。然而，由于改造的要求，适应性维护和完善性维护的工作量逐步增加，在这种维护过程中又会引入新的错误，从而加重了维护的工作量。实践表明，在几种维护活动中，完善性维护所占的比重最大，即大部分维护工作是改变和加强软件，而不是纠错。用户要求扩充、加强软件功能、性能的维护活动约占整个维护工作的50％。

11.1 软件维护的种类 完善性维护 50％预防性维护5％适应性维护 25％改正性维护 20％图11.1 各类维护的比重

11.2 软件维护的特点 • 11.2.1 软件维护面临的困难 • 统计资料表明，有代表性的软件开发组织用于校正性维护、适应性维护、完善性维护及预防性维护的费用占其开发总金额的70％至80％。 • 很多软件机构被束缚在维护工作上，这是软件维护所带来的无形支出。

11.2.2 产生软件维护问题的根源 • 软件维护中出现的大多数问题，究其根源往往是由于软件开发计划及开发方法方面的缺陷造成的。 • 软件维护就是弥补软件设计和开发过程中的缺陷。 • 客户可能会无休止地要求“维修”那些新出来的问题或要求改进，修改的成本很高 • 任何考虑不周到的变动都可能造成软件系统不能正常运转，甚至给软件系统造成不可恢复的灾难

11.2.3 非结构化维护 • 无说明或者文档资料太少由于没有采用定义良好的软件项目管理过程来开发软件，软件项目管理的缺陷导致的叫“非结构化维护”,这会使软件维护付出较高的代价.

11.2.4 结构化维护 • 存在完整的软件系列文档，那么维护任务就从分析设计文件开始，确定软件的重要结构特性、功能特性和接口特性，确定所要求的修改或校正可能产生的影响，并且计划采用何种维护处理方法，修改设计并进行复审，编制出新的源程序，利用文档中的信息进行回归测试，然后重新交付软件。这种维护过程就叫做“结构化维护”

11.3 软件维护的实施 • 为了有效地进行软件维护，应事先就开始做组织工作。首先需要建立维护的机构，申明提出维护申请报告的过程及评价的过程；为每一个维护申请规定标准的处理步骤；还必须建立维护活动的登记制度以及规定评价和评审的标准。

11.3.2 软件维护申请报告 • 软件维护申请应按规定的方式提出。软件维护组织通常提供维护申请报告(MRR， Maintenance Request Report)，或称软件问题报告，由申请维护的用户填写。

图11.2软件维护的组织结构 维护管理员系统监督员维护配置员维护负责人维护小组1 维护负责人维护小组n 维护负责人维护小组2 维护负责人维护小组3 11.3.1 维护机构

11.3.1 维护机构 • 维护申请提交给一个维护管理员，他把申请交给某个系统监督员去评价。系统监督员是一位技术人员，他必须熟悉产品程序的某一部分。一旦做出评价，由修改负责人确定如何进行修改。维护人员对程序进行修改的过程中，由配置管理员严格把关，控制修改的范围，对软件配置进行审计。 • 维护管理员、系统监督员、修改负责人等，均代表维护工作的某个职责范围。修改负责人、维护管理员可以是指定的某个人，也可以是一个包括管理人员、高级技术人员在内的小组。系统监督员可以有其他职责，但应具体分管某一个软件包。

11.3.2 软件维护申请报告 • 软件维护申请应按规定的方式提出。软件维护组织通常提供维护申请报告(MRR， Maintenance Request Report)，或称软件问题报告，由申请维护的用户填写。维护申请报告是由软件组织外部提交的文档，它是计划维护工作的基础。软件组织内部应相应地做出软件修改报告(SCR，Software Change Report)，指明： • (1) 所需修改变动的性质； • (2) 申请修改的优先级； • (3) 为满足某个维护申请报告，所需的工作量； • (4) 预计修改后的状况。 • 软件修改报告应提交修改负责人，经批准后才能开始进一步安排维护工作。

申请维护 改正性维护适应性维护何种维护完善性维护问题严重确定优先顺序否应性维护指定人员是应性维护排到日程确定优先顺序开始分析问题是应性维护否应性维护排到日程等待编写程序测试否应性维护等待否应性维护复审合格是应性维护交付文档程序图11.3软件维护工作流程 11.3.3 软件维护工作流程

11.3.4 维护档案记录 • 为了估计软件维护的有效程度，确定软件产品的质量，同时确定维护的实际开销，需要在维护的过程中做好维护档案记录。 • 其内容包括程序名称、源程序语句条数、机器代码指令条数、所用的程序设计语言、程序安装的日期、程序安装后的运行次数、与程序安装后运行次数有关的处理故障次数、程序改变的层次及名称、修改程序所增加的源程序语句条数、修改程序所减少的源程序语句条数、每次修改所付出的“人时”数、修改程序的日期、软件维护人员的姓名、维护申请报告的名称、维护类型、维护开始时间和维护结束时间、花费在维护上的累计“人时”数、维护工作的净收益等

11.3.5 维护评价 • 每次程序运行时的平均出错次数； • ·花费在每类维护上的总“人时”数； • ·每个程序、每种语言、每种维护类型的程序平均修改次数； • ·因为维护，增加或删除每个源程序语句所花费的平均“人时”数； • ·用于每种语言的平均“人时”数； • ·维护申请报告的平均处理时间； • ·各类维护申请的百分比。 • 这七种度量值提供了定量的数据，据此可对开发技术、语言选择、维护工作计划、资源分配以及其他许多方面做出判定。因此，这些数据可以用来评价维护工作。

11.4 软件的可维护性 • 11.4.1 影响可维护性的因素 • 软件的可维护性可以简单定义为：纠正软件系统出现的错误和缺陷,以满足新的要求, 能够被理解、被校正、被修改或被改善的难易程度。可维护性不但与采用的分析设计方法和开发人员的技术熟练程度有关，更重要的是与软件项目的管理技术关系密切。软件的可维护性成为软件开发阶段各个时期的关键目标。

11.4.1 影响可维护性的因素 • 除了与开发方法有关的因素之外，以下因素会对可维护性有重要影响： • （1）软件设计人员是否受到严格的规范化工作培训； • （2）是否采用主流的编程语言； • （3）是否采用主流的操作系统； • （4）是否采用标准化的文档资料结构和文档形成机制； • （5）是否保存规范化的测试资料。

11.4.2 软件可维护性的度量 • 1. 可理解性 • 2. 可靠性 • 可靠性，度量的标准主要有：平均失效间隔时间MTTF(Mean Time To Failure)、平均修复时间MTTR(Mean Time To Repair error)、有效性A • (1) 根据程序错误统计数字，进行可靠性预测。 • (2) 根据程序复杂性，预测软件可靠性。

11.4.2 软件可维护性的度量 • 3. 可测试性 • 4. 可修改性 • 5. 可移植性 • 6. 效率 • 7. 可使用性 • 8. 间接度量可维护性的方法

11.4.2 软件可维护性的度量 • 8. 间接度量可维护性的方法 • (1) 了解问题的时间； • (2) 行政管理拖延的时间； • (3) 收集维护工具的时间； • (4) 分析问题的时间； • (5) 改变规格说明的时间； • (6) 具体的改错或修改的时间； • (7) 局部测试时间； • (8) 整体测试时间； • (9) 维护重审时间； • (10) 总体恢复时间。

11.4.3 提高可维护性的方法 • 1. 建立明确的软件质量目标和优先级 • 一个可维护的程序应是可理解的、可靠的、可测试的、可修改的、可移植的、效率高的、可使用的。 • 尽管可维护性要求每—种质量特性都要得到满足，但它们的相对重要性应随程序的用途及计算环境的不同而不同。所以当对程序的质量特性，在提出目标的同时还必须规定它们的优先级。 • 2. 使用提高软件质量的技术和工具 • (1) 模块化和结构化程序设计 • (2) 使用结构化程序设计技术，提高现有系统的可维护性

11.4.3 提高可维护性的方法 • 3. 进行明确的质量保证审查 • 4. 验收检查 • 验收检查是一个特殊的检查点的检查，是交付使用前的最后一次检查，是软件投入运行之前保证可维护性的最后机会。 • (1) 需求和规范标准：需求应当以可测试的术语进行书写，排列优先次序和定义； • (2) 设计标准：程序应设计成分层的模块结构，每个模块应完成唯一的功能，并达 • (3) 源代码标准尽可能使用最高级的程序设计语言，且只使用语言的标准版本 • (4) 文档标准：文档中应说明程序的输入／输出

11.4.3 提高可维护性的方法 • 5. 周期性地维护审查 • 6. 选择可维护的程序设计语言 • 7. 健全程序的文档 • 好的文档是建立可维护性的基本条件，它的作用和意义有三点： • (1) 文档好的程序比没有文档的程序容易操作，因为它增加了程序的可读性和可使用性。但不正确的文档比根本没有文档要坏得多。 • (2) 好的文档意味着简洁、风格一致且易于更新。 • (3) 程序应当成为其自身的文档，也就是说，在程序中应插入注释，以提高程序的可理解性，并缩进、空行等明显的视觉组织来突出程序的控制结构。如果程序越长越复杂，则它对文档的需要就越迫切。

11.4.3 提高可维护性的方法 • 在软件维护阶段，要利用历史文档 • 历史文档有三种： •  系统开发日志： •  运行记录 •  系统维护日志：记录在维护阶段对系统修改和相关信息。

11.5 软件维护的副作用 • 软件维护可能产生副作用，这里副作用是指由于修改软件而造成的错误或发生其他不希望发生的情况。修改的内容不同，副作用也不一样。

1. 修改软件源程序的副作用 • 最危险的副作用是修改软件源程序而产生的，每当对一个复杂的逻辑过程做了一处修改，出错的可能性就增大了。下列对源程序的修改更易产生错误： • (1) 改变一个子程序、函数、变量定义 • (2) 为改进运行性能所作的修改 • (3) 改变了逻辑运算过程 • (4) 设计的变动造成了较大的程序变动 • (5) 改变了边界测试条件

2. 修改数据的副作用 • 一般是由于修改软件特定的信息结构所引起的 • (1) 新定义局部的及全程的常数 • (2) 重新定义记录和文件的格式 • (3) 改变一个数组的大小或改变高层数据结构的大小 • (4) 对控制标志或指针的重新初始化 • (5) 重新安排输人输出参量。

3. 修改文档资料的副作用 • 每当改动数据流、软件结构、模块过程或任何其他有关特性时，有关的技术文档资料必须要相应地更新

第 11 章软件维护