图74三类维护占总维护比例 图75维护在软件生存期所占比例 ④预防性维护 除了以上三类维护之外,还有一类维护活动,叫做预防性维护。这是为了提高软件的可 维护性、可靠性等,为以后进一步改进软件打下良好基础。通常,预防性维护定义为:“把今 天的方法学用于昨天的系统以满足明天的需要”。也就是说,采用先进的软件工程方法对需要 维护的软件或软件中的某一部分(重新)进行设计、编制和测试 在整个软件维护阶段所花费的全部工作量中,预防性维护只占很小的比例,而完善性维护占 了几乎一半的工作量。参看图74。从图75中可以看到,软件维护活动所花费的工作占整个 生存期工作量的70%以上 (2)影响维护工作量的因素 在软件维护中,影响维护工作量的程序特性有以下6种。 系统大小:系统越大,理解掌握起来越困难。系统越大,所执行功能越复杂。因而需 要更多的维护工作量。 程序设计语言:语言的功能越强,生成程序所需的指令数就越少;语言的功能越弱, 实现同样功能所需语句就越多,程序就越大。有许多软件是用较老的程序设计语言书写的 程序逻辑复杂而混乱,且没有做到模块化和结构化,直接影响到程序的可读性。 ■系统年龄:老系统随着不断的修改,结构越来越乱;由于维护人员经常更换,程序又 变得越来越难于理解。而且许多老系统在当初并未按照软件工程的要求进行开发,因而没有 文档,或文档太少,或在长期的维护过程中文档在许多地方与程序实现变得不一致,这样在 维护时就会遇到很大困难。 数据库技术的应用:使用数据库,可以简单而有效地管理和存储用户程序中的数据, 还可以减少生成用户报表应用软件的维护工作量 先进的软件开发技术:在软件开发时,若使用能使软件结构比较稳定的分析与设计技 术,及程序设计技术,如面向对象技术、复用技术等,可减少大量的工作量 ■其它:例如,应用的类型、数学模型、任务的难度、开关与标记、IF嵌套深度、索引 或下标数等,对维护工作量都有影响 此外,许多软件在开发时并未考虑将来的修改,这就为软件的维护带来许多问题 3)软件维护的策略 根据影响软件维护工作量的各种因素,针对三种典型的维护, James martin等提出了一 些策略,以控制维护成本。 ①改正性维护 要生成100%可靠的软件成本太高,不一定合算。但通过使用新技术,可大大提高可靠 减少进行改正性维护的需要。这些技术包括:数据库管理系统、软件开发环境、程序自 生成系统、较高级(第四代)的语言,应用以上4种方法可产生更加可靠的代码。此外 利用应用软件包,可开发出比由用户完全自己开发的系统可靠性更高的软件。 结构化技术,用它开发的软件易于理解和测试 防错性程序设计。把自检能力引入程序,通过非正常状态的检査,提供审査跟踪。 通过周期性维护审査,在形成维护问题之前就可确定质量缺陷 ②适应性维护 这一类的维护不可避免,但可以控制。 在配置管理时,把硬件、操作系统和其它相关环境因素的可能变化考虑在内,可以减 少某些适应性维护的工作量。 把与硬件、操作系统,以及其它外围设备有关的程序归到特定的程序模块中。可把因
6 图 7.4 三类维护占总维护比例 图 7.5 维护在软件生存期所占比例 ④ 预防性维护 除了以上三类维护之外，还有一类维护活动，叫做预防性维护。这是为了提高软件的可 维护性、可靠性等，为以后进一步改进软件打下良好基础。通常，预防性维护定义为：“把今 天的方法学用于昨天的系统以满足明天的需要”。也就是说，采用先进的软件工程方法对需要 维护的软件或软件中的某一部分(重新)进行设计、编制和测试。 在整个软件维护阶段所花费的全部工作量中，预防性维护只占很小的比例，而完善性维护占 了几乎一半的工作量。参看图 7.4。从图 7.5 中可以看到，软件维护活动所花费的工作占整个 生存期工作量的 70%以上。 (2) 影响维护工作量的因素 在软件维护中，影响维护工作量的程序特性有以下 6 种。 ▪ 系统大小：系统越大，理解掌握起来越困难。系统越大，所执行功能越复杂。因而需 要更多的维护工作量。 ▪ 程序设计语言：语言的功能越强，生成程序所需的指令数就越少；语言的功能越弱， 实现同样功能所需语句就越多，程序就越大。有许多软件是用较老的程序设计语言书写的， 程序逻辑复杂而混乱，且没有做到模块化和结构化，直接影响到程序的可读性。 ▪ 系统年龄：老系统随着不断的修改，结构越来越乱；由于维护人员经常更换，程序又 变得越来越难于理解。而且许多老系统在当初并未按照软件工程的要求进行开发，因而没有 文档，或文档太少，或在长期的维护过程中文档在许多地方与程序实现变得不一致，这样在 维护时就会遇到很大困难。 ▪ 数据库技术的应用：使用数据库，可以简单而有效地管理和存储用户程序中的数据， 还可以减少生成用户报表应用软件的维护工作量。 ▪ 先进的软件开发技术：在软件开发时，若使用能使软件结构比较稳定的分析与设计技 术，及程序设计技术，如面向对象技术、复用技术等，可减少大量的工作量。 ▪ 其它：例如，应用的类型、数学模型、任务的难度、开关与标记、IF 嵌套深度、索引 或下标数等，对维护工作量都有影响。 此外，许多软件在开发时并未考虑将来的修改，这就为软件的维护带来许多问题。 (3) 软件维护的策略 根据影响软件维护工作量的各种因素，针对三种典型的维护，James Martin 等提出了一 些策略，以控制维护成本。 ① 改正性维护 要生成 100％可靠的软件成本太高，不一定合算。但通过使用新技术，可大大提高可靠 性，减少进行改正性维护的需要。这些技术包括：数据库管理系统、软件开发环境、程序自 动生成系统、较高级(第四代)的语言，应用以上 4 种方法可产生更加可靠的代码。此外， ▪ 利用应用软件包，可开发出比由用户完全自己开发的系统可靠性更高的软件。 ▪ 结构化技术，用它开发的软件易于理解和测试。 ▪ 防错性程序设计。把自检能力引入程序，通过非正常状态的检查，提供审查跟踪。 ▪ 通过周期性维护审查，在形成维护问题之前就可确定质量缺陷。 ② 适应性维护 这一类的维护不可避免，但可以控制。 ▪ 在配置管理时，把硬件、操作系统和其它相关环境因素的可能变化考虑在内，可以减 少某些适应性维护的工作量。 ▪ 把与硬件、操作系统，以及其它外围设备有关的程序归到特定的程序模块中。可把因
环境变化而必须修改的程序局部于某些程序模块之中 ■使用内部程序列表、外部文件,以及处理的例行程序包,可为维护时修改程序提供方 ③完善性维护 利用前两类维护中列举的方法,也可以减少这一类维护。特别是数据库管理系统、程序 主成器、应用软件包,可减少系统或程序员的维护工作量。 此外,建立软件系统的原型,把它在实际系统开发之前提供给用户。用户通过研究原型, 进一步完善他们的功能要求,就可以减少以后完善性维护的需要 (4)维护成本 有形的软件维护成本是花费了多少钱,而其它非直接的的维护成本有更大的影响。例如 无形的成本可以是 些看起来是合理的修复或修改请求不能及时安排,使得客户不满意 变更的结果把一些潜在的错误引入正在维护的软件,使得软件整体质量下降: 当必须把软件人员抽调到维护工作中去时,就使得软件开发工作受到干扰 软件维护的代价是在生产率方面的惊人下降。有报告说,生产率将降到原来的40分之 。维护工作量可以分成生产性活动(如分析和评价、设计修改和实现)和“轮转”活动(如力 图理解代码在做什么、试图判明数据结构、接口特性、性能界限等)。下面的公式给出了一个 维护工作量的模型: M=p+ke 其中,M是维护中消耗的总工作量,p是上面描述的生产性工作量,K是一个经验常数,c 是因缺乏好的设计和文档而导致复杂性的度量,d是对软件熟悉程度的度量。 这个模型指明,如果使用了不好的软件开发方法(未按软件工程要求做),原来参加开发 的人员或小组不能参加维护,则工作量(及成本)将按指数级增加。 3.软件维护活动 (1)维护机构 除了较大的软件开发公司外,通常在软件维护工作方面,不保持正式的维护机构。维护 往往是在没有计划的情况下进行的。虽然不要求建立一个正式的维护机构,但是在开发部门, 确立一个非正式的维护机构则是非常必要的。例如图76就是一个维护机构的组织方案 修改负责人 申请维护 维护管理员 系统监督员 配置管理员 维护人员
7 环境变化而必须修改的程序局部于某些程序模块之中。 ▪ 使用内部程序列表、外部文件，以及处理的例行程序包，可为维护时修改程序提供方 便。 ③ 完善性维护 利用前两类维护中列举的方法，也可以减少这一类维护。特别是数据库管理系统、程序 生成器、应用软件包，可减少系统或程序员的维护工作量。 此外，建立软件系统的原型，把它在实际系统开发之前提供给用户。用户通过研究原型， 进一步完善他们的功能要求，就可以减少以后完善性维护的需要。 (4) 维护成本 有形的软件维护成本是花费了多少钱，而其它非直接的的维护成本有更大的影响。例如， 无形的成本可以是： ▪ 一些看起来是合理的修复或修改请求不能及时安排，使得客户不满意； ▪ 变更的结果把一些潜在的错误引入正在维护的软件，使得软件整体质量下降； ▪ 当必须把软件人员抽调到维护工作中去时，就使得软件开发工作受到干扰。 软件维护的代价是在生产率方面的惊人下降。有报告说，生产率将降到原来的 40 分之 一。维护工作量可以分成生产性活动(如分析和评价、设计修改和实现)和“轮转”活动(如力 图理解代码在做什么、试图判明数据结构、接口特性、性能界限等)。下面的公式给出了一个 维护工作量的模型： c d M p Ke − = + 其中，M 是维护中消耗的总工作量，p 是上面描述的生产性工作量，K 是一个经验常数，c 是因缺乏好的设计和文档而导致复杂性的度量，d 是对软件熟悉程度的度量。 这个模型指明，如果使用了不好的软件开发方法(未按软件工程要求做)，原来参加开发 的人员或小组不能参加维护，则工作量(及成本)将按指数级增加。 3. 软件维护活动 (1) 维护机构 除了较大的软件开发公司外，通常在软件维护工作方面，不保持正式的维护机构。维护 往往是在没有计划的情况下进行的。虽然不要求建立一个正式的维护机构，但是在开发部门， 确立一个非正式的维护机构则是非常必要的。例如图 7.6 就是一个维护机构的组织方案
图76软件维护的机构 维护申请提交给一个维护管理员,他把申请交给某个系统监督员去评价。一旦做出评价, 由修改负责人确定如何进行修改。在维护人员对程序进行修改的过程中,由配置管理员严格 把关,控制修改的范围,对软件配置进行审计。 维护管理员、系统监督员、修改负责人等,均代表维护工作的某个职责范围。修改负责 人、维护管理员可以是指定的某个人,也可以是一个包括管理人员、高级技术人员在内的小 组。系统监督员可以有其他职责,但应具体分管某一个软件包。 在开始维护之前,就把责任明确下来,可以大大减少维护过程中的混乱。 (2)软件维护工作流程 先确认维护要求。这需要维护人员与用户反复协商,弄清错误概况以及对业务的影响 大小,以及用户希望做什么样的修改。然后由维护组织管理员确认维护类型。 对于改正性维护申请,从评价错误的严重性开始。如果存在严重的错误,则必须安排 人员,在系统监督员的指导下,进行问题分析,寻找错误发生的原因,进行“救火”性的紧 急维护;对于不严重的错误,可根据任务、机时情况、视轻重缓急,进行排队,统一安排时 对于适应性维护和完善性维护申请,需要先确定每项申请的优先次序。若某项申请的 优先级非常高,就可立即开始维护工作,否则,维护申请和其它的开发工作一样,进行排队, 统一安排时间 尽管维护申请的类型不同,但都要进行同样的技术工作。这些工作有:修改软件需求 说明、修改软件设计、设计评审、对源程序做必要的修改、单元测试、集成测试(回归测试) 确认测试、软件配置评审等 ■在每次软件维护任务完成后,最好进行一次情况评审,确认:在目前情况下,设计、 编码、测试中的哪一方面可以改进?哪些维护资源应该有但没有?工作中主要的或次要的障 碍是什么?从维护申请的类型来看是否应当有预防性维护? (3)维护评价 评价维护活动比较困难,因为缺乏可靠的数据。但如果维护记录做得比较好,就可以得 出一些维护“性能”方面的度量值。可参考的度量值如: 每次程序运行时的平均出错次数 花费在每类维护上的总“人时”数 每个程序、每种语言、每种维护类型的程序平均修改次数 因为维护,增加或删除每个源程序语句所花费的平均“人时”数: 用于每种语言的平均“人时”数 维护申请报告的平均处理时间 各类维护申请的百分比。 这七种度量值提供了定量的数据,据此可对开发技术、语言选择、维护工作计划、资源 分配、以及其它许多方面做出判定。因此,这些数据可以用来评价维护工作 4.程序修改的步骤及修改的副作用 (1)分析和理解程序 经过分析,全面、准确、迅速地理解程序是决定维护成败和质量好坏的关键。在这方面, 软件的可理解性和文档的质量非常重要。必须: 理解程序的功能和目标 掌握程序的结构信息,即从程序中细分出若干结构成分。如程序系统结构、控制结
8 图 7.6 软件维护的机构 维护申请提交给一个维护管理员，他把申请交给某个系统监督员去评价。一旦做出评价， 由修改负责人确定如何进行修改。在维护人员对程序进行修改的过程中，由配置管理员严格 把关，控制修改的范围，对软件配置进行审计。 维护管理员、系统监督员、修改负责人等，均代表维护工作的某个职责范围。修改负责 人、维护管理员可以是指定的某个人，也可以是一个包括管理人员、高级技术人员在内的小 组。系统监督员可以有其他职责，但应具体分管某一个软件包。 在开始维护之前，就把责任明确下来，可以大大减少维护过程中的混乱。 (2) 软件维护工作流程 ▪ 先确认维护要求。这需要维护人员与用户反复协商，弄清错误概况以及对业务的影响 大小，以及用户希望做什么样的修改。然后由维护组织管理员确认维护类型。 ▪ 对于改正性维护申请，从评价错误的严重性开始。如果存在严重的错误，则必须安排 人员，在系统监督员的指导下，进行问题分析，寻找错误发生的原因，进行“救火”性的紧 急维护； 对于不严重的错误，可根据任务、机时情况、视轻重缓急，进行排队，统一安排时 间。 ▪ 对于适应性维护和完善性维护申请，需要先确定每项申请的优先次序。若某项申请的 优先级非常高，就可立即开始维护工作，否则，维护申请和其它的开发工作一样，进行排队， 统一安排时间。 ▪ 尽管维护申请的类型不同，但都要进行同样的技术工作。这些工作有：修改软件需求 说明、修改软件设计、设计评审、对源程序做必要的修改、单元测试、集成测试( 回归测试)、 确认测试、软件配置评审等。 ▪ 在每次软件维护任务完成后，最好进行一次情况评审，确认：在目前情况下，设计、 编码、测试中的哪一方面可以改进？哪些维护资源应该有但没有？工作中主要的或次要的障 碍是什么？从维护申请的类型来看是否应当有预防性维护？ (3) 维护评价 评价维护活动比较困难，因为缺乏可靠的数据。但如果维护记录做得比较好，就可以得 出一些维护“性能”方面的度量值。可参考的度量值如： ▪ 每次程序运行时的平均出错次数； ▪ 花费在每类维护上的总“人时”数； ▪ 每个程序、每种语言、每种维护类型的程序平均修改次数； ▪ 因为维护，增加或删除每个源程序语句所花费的平均“人时”数； ▪ 用于每种语言的平均“人时”数； ▪ 维护申请报告的平均处理时间； ▪ 各类维护申请的百分比。 这七种度量值提供了定量的数据，据此可对开发技术、语言选择、维护工作计划、资源 分配、以及其它许多方面做出判定。因此，这些数据可以用来评价维护工作。 4. 程序修改的步骤及修改的副作用 (1) 分析和理解程序 经过分析，全面、准确、迅速地理解程序是决定维护成败和质量好坏的关键。在这方面， 软件的可理解性和文档的质量非常重要。必须： ▪ 理解程序的功能和目标； ▪ 掌握程序的结构信息，即从程序中细分出若干结构成分。如程序系统结构、 控制结
构、数据结构和输入/输出结构等 了解数据流信息,即所涉及到的数据来源何处,在哪里被使用 了解控制流信息,即执行每条路径的结果; 理解程序的操作(使用)要求 为了容易地理解程序,要求自顶向下地理解现有源程序的程序结构和数据结构,为此可 采用如下方法 ①分析程序结构图: 分析各个过程的源代码,建立一个直接调用矩阵D或调用树。 建立过程的间接调用矩阵 分析各个过程的接口,估计更改的复杂性。 ②数据跟踪 建立各层次的程序级上的接口图,展示各模块或过程的调用方式和接口参数 ■利用数据流分析方法,对过程内部的一些变量进行跟踪:维护人员通过这种数据流跟 可获得有关数据在过程间如何传递,在过程内如何处理等信息 ③控制跟踪 控制流跟踪同样可在结构图基础上或源程序基础上进行。可采用符号执行或实际动态跟 踪的方法,了解数据如何从一个输入源到达输出点的 ④在分析的过程中,充分阅读和使用源程序清单和文档,分析现有文档的合理性。 ⑤充分使用由编译程序或汇编程序提供的交叉引用表、符号表、以及其它有用的信息。 ⑥如有可能,积极参加开发工作。 (2)修改程序 对程序的修改,必须事先做出计划,有预谋地、周密有效地实施修改。 ①设计程序的修改计划 程序的修改计划要考虑人员和资源的安排。修改计划的内容主要包括: 规格说明信息:数据修改、处理修改、作业控制语言修改、系统之间接口的修改等; ■维护资源:新程序版本、测试数据、所需的软件系统、计算机时间等 人员:程序员、用户相关人员、技术支持人员、厂家联系人、数据录入员等; 提供:纸面、计算机媒体等 针对以上每一项,要说明必要性、从何处着手、是否接受、日期等。通常,可采用自顶 向下的方法,在理解程序的基础上, i)研究程序的各个模块、模块的接口、及数据库,从全局的观点,提出修改计划。 ⅱ)依次地把要修改的、以及那些受修改影响的模块和数据结构分离出来。为此,要 识别受修改影响的数据 识别使用这些数据的程序模块 对于上面程序模块,按是产生数据、修改数据、还是删除数据进行分类 识别对这些数据元素的外部控制信息; 识别编辑和检查这些数据元素的地方 隔离要修改的部分 i)详细地分析要修改的、以及那些受变更影响的模块和数据结构的内部细节,设计修 改计划,标明新逻辑及要改动的现有逻辑。 iv)向用户提供回避措施。用户的某些业务因软件中发生问题而中断,为不让系统长时 间停止运行,需把问题局部化,在可能的范围内继续开展业务。可以采取的措施有 在问题的原因还未找到时,先就问题的现象,提供回避的操作方法 如果弄清了问题的原因,可通过临时修改或改变运行控制以回避在系统运行时产生
9 构、数据结构和输入／输出结构等； ▪ 了解数据流信息，即所涉及到的数据来源何处，在哪里被使用； ▪ 了解控制流信息，即执行每条路径的结果； ▪ 理解程序的操作(使用)要求； 为了容易地理解程序，要求自顶向下地理解现有源程序的程序结构和数据结构，为此可 采用如下方法： ① 分析程序结构图： ▪ 分析各个过程的源代码，建立一个直接调用矩阵 D 或调用树。 ▪ 建立过程的间接调用矩阵。 ▪ 分析各个过程的接口，估计更改的复杂性。 ② 数据跟踪 ▪ 建立各层次的程序级上的接口图，展示各模块或过程的调用方式和接口参数； ▪ 利用数据流分析方法，对过程内部的一些变量进行跟踪；维护人员通过这种数据流跟 踪，可获得有关数据在过程间如何传递，在过程内如何处理等信息。 ③ 控制跟踪 控制流跟踪同样可在结构图基础上或源程序基础上进行。可采用符号执行或实际动态跟 踪的方法，了解数据如何从一个输入源到达输出点的。 ④ 在分析的过程中，充分阅读和使用源程序清单和文档，分析现有文档的合理性。 ⑤ 充分使用由编译程序或汇编程序提供的交叉引用表、符号表、以及其它有用的信息。 ⑥ 如有可能，积极参加开发工作。 (2) 修改程序 对程序的修改，必须事先做出计划，有预谋地、周密有效地实施修改。 ① 设计程序的修改计划 程序的修改计划要考虑人员和资源的安排。修改计划的内容主要包括： ▪ 规格说明信息：数据修改、处理修改、作业控制语言修改、系统之间接口的修改等； ▪ 维护资源：新程序版本、测试数据、所需的软件系统、计算机时间等； ▪ 人员：程序员、用户相关人员、技术支持人员、厂家联系人、数据录入员等； ▪ 提供：纸面、计算机媒体等。 针对以上每一项，要说明必要性、从何处着手、是否接受、日期等。通常，可采用自顶 向下的方法，在理解程序的基础上， ⅰ) 研究程序的各个模块、模块的接口、及数据库，从全局的观点，提出修改计划。 ⅱ) 依次地把要修改的、以及那些受修改影响的模块和数据结构分离出来。为此，要 ▪ 识别受修改影响的数据； ▪ 识别使用这些数据的程序模块； ▪ 对于上面程序模块，按是产生数据、修改数据、还是删除数据进行分类； ▪ 识别对这些数据元素的外部控制信息； ▪ 识别编辑和检查这些数据元素的地方； ▪ 隔离要修改的部分； ⅲ) 详细地分析要修改的、以及那些受变更影响的模块和数据结构的内部细节，设计修 改计划，标明新逻辑及要改动的现有逻辑。 ⅳ) 向用户提供回避措施。用户的某些业务因软件中发生问题而中断，为不让系统长时 间停止运行，需把问题局部化，在可能的范围内继续开展业务。可以采取的措施有： ▪ 在问题的原因还未找到时，先就问题的现象，提供回避的操作方法。 ▪ 如果弄清了问题的原因，可通过临时修改或改变运行控制以回避在系统运行时产生
的问题 ②修改代码,以适应变化 正确、有效地编写修改代码 要谨慎地修改程序,尽量保持程序的风格及格式,要在程序清单上注明改动的指令 不要删除程序语句,除非完全肯定它是无用的 不要试图共用程序中已有的临时变量或工作区,为了避免冲突或混淆用途,应自行设 置自己的变量 插入错误检测语句 在修改过程中做好修改的详细记录,消除变更中任何有害的副作用(波动效应) ③修改程序的副作用 所谓副作用是指因修改软件而造成的错误或其它不希望发生的情况,有三种副作用: 修改代码的副作用。在使用程序设计语言修改源代码时,都可能引入错误。例如,删 除或修改一个子程序、删除或修改一个标号、删除或修改一个标识符、改变程序代码的时序 关系、改变占用存储的大小、改变逻辑运算符、修改文件的打开或关闭、改进程序的执行效 率,以及把设计上的改变翻译成代码的改变、为边界条件的逻辑测试做出改变时,都容易引 入错误 ■修改数据的副作用。在修改数据结构时,有可能造成软件设计与数据结构不匹配,因 而导致软件出错。数据副作用就是修改软件信息结构导致的结果。例如,在重新定义局部的 或全局的常量、重新定义记录或文件的格式、增大或减小一个数组或高层数据结构的大小 修改全局或公共数据、重新初始化控制标志或指针、重新排列输入/输出或子程序的参数时, 容易导致设计与数据不相容的错误。数据副作用可以通过详细的设计文档加以控制。在此文 档中描述了一种交叉引用,把数据元素、记录、文件和其它结构联系起来 文档的副作用。对数据流、软件结构、模块逻辑或任何其它有关特性进行修改时, 必须对相关技术文档进行相应修改。否则会导致文档与程序功能不匹配,缺省条件改变,新 错误信息不正确等错误。使得软件文档不能反映软件的当前状态。对于用户来说,软件事实 上就是文档。如果对可执行软件的修改不反映在文档里,就会产生文档的副作用。例如,对 交互输入的顺序或格式进行修改,如果没有正确地记入文档中,就可能引起重大的问题。过 时的文档内容、索引和文本可能造成冲突,引起用户的失败和不满。因此,必须在软件交付 之前对整个软件配置进行评审,以减少文档的副作用。 为了控制因修改而引起的副作用,要做到: i)按模块把修改分组 ⅱ)自顶向下地安排被修改模块的顺序: ⅲi)每次修改一个模块; iv)对于每个修改了的模块,在安排修改下一个模块之前,要确定这个修改的副作用 可以使用交叉引用表、存储映象表、执行流程跟踪等。 (3)重新验证程序 在将修改后的程序提交用户之前,需要用以下的方法进行充分的确认和测试,以保证整 个修改后的程序的正确性 ①静态确认 修改软件,伴随着引起新的错误的危险。为了能够做出正确的判断,验证修改后的程序 至少需要两个人参加。要检查 ■修改是否涉及到规格说眀?修改结果是否符合规格说明?有没有歪曲规格说明? 程序的修改是否足以修正软件中的问题?源程序代码有无逻辑错误?修改时有无修补 失误?
10 的问题。 ② 修改代码，以适应变化 ▪ 正确、有效地编写修改代码； ▪ 要谨慎地修改程序，尽量保持程序的风格及格式，要在程序清单上注明改动的指令； ▪ 不要删除程序语句，除非完全肯定它是无用的； ▪ 不要试图共用程序中已有的临时变量或工作区，为了避免冲突或混淆用途，应自行设 置自己的变量； ▪ 插入错误检测语句； ▪ 在修改过程中做好修改的详细记录，消除变更中任何有害的副作用(波动效应）； ③ 修改程序的副作用 所谓副作用是指因修改软件而造成的错误或其它不希望发生的情况，有三种副作用： ▪ 修改代码的副作用。在使用程序设计语言修改源代码时，都可能引入错误。例如，删 除或修改一个子程序、删除或修改一个标号、 删除或修改一个标识符、改变程序代码的时序 关系、改变占用存储的大小、改变逻辑运算符、修改文件的打开或关闭、改进程序的执行效 率，以及把设计上的改变翻译成代码的改变、为边界条件的逻辑测试做出改变时，都容易引 入错误。 ▪ 修改数据的副作用。在修改数据结构时，有可能造成软件设计与数据结构不匹配，因 而导致软件出错。数据副作用就是修改软件信息结构导致的结果。例如，在重新定义局部的 或全局的常量、 重新定义记录或文件的格式、增大或减小一个数组或高层数据结构的大小、 修改全局或公共数据、重新初始化控制标志或指针、重新排列输入／输出或子程序的参数时， 容易导致设计与数据不相容的错误。数据副作用可以通过详细的设计文档加以控制。在此文 档中描述了一种交叉引用，把数据元素、记录、文件和其它结构联系起来。 ▪ 文档的副作用。对数据流、软件结构、 模块逻辑或任何其它有关特性进行修改时， 必须对相关技术文档进行相应修改。否则会导致文档与程序功能不匹配，缺省条件改变，新 错误信息不正确等错误。使得软件文档不能反映软件的当前状态。对于用户来说，软件事实 上就是文档。如果对可执行软件的修改不反映在文档里，就会产生文档的副作用。例如，对 交互输入的顺序或格式进行修改，如果没有正确地记入文档中，就可能引起重大的问题。过 时的文档内容、索引和文本可能造成冲突，引起用户的失败和不满。因此，必须在软件交付 之前对整个软件配置进行评审，以减少文档的副作用。 为了控制因修改而引起的副作用，要做到： ⅰ) 按模块把修改分组； ⅱ) 自顶向下地安排被修改模块的顺序； ⅲ) 每次修改一个模块； ⅳ) 对于每个修改了的模块，在安排修改下一个模块之前，要确定这个修改的副作用。 可以使用交叉引用表、存储映象表、执行流程跟踪等。 (3) 重新验证程序 在将修改后的程序提交用户之前，需要用以下的方法进行充分的确认和测试，以保证整 个修改后的程序的正确性。 ① 静态确认 修改软件，伴随着引起新的错误的危险。为了能够做出正确的判断，验证修改后的程序 至少需要两个人参加。要检查 ▪ 修改是否涉及到规格说明? 修改结果是否符合规格说明? 有没有歪曲规格说明? ▪ 程序的修改是否足以修正软件中的问题? 源程序代码有无逻辑错误? 修改时有无修补 失误?