的问题 ②修改代码,以适应变化 正确、有效地编写修改代码 要谨慎地修改程序,尽量保持程序的风格及格式,要在程序清单上注明改动的指令 不要删除程序语句,除非完全肯定它是无用的 不要试图共用程序中已有的临时变量或工作区,为了避免冲突或混淆用途,应自行设 置自己的变量 插入错误检测语句 在修改过程中做好修改的详细记录,消除变更中任何有害的副作用(波动效应) ③修改程序的副作用 所谓副作用是指因修改软件而造成的错误或其它不希望发生的情况,有三种副作用: 修改代码的副作用。在使用程序设计语言修改源代码时,都可能引入错误。例如,删 除或修改一个子程序、删除或修改一个标号、删除或修改一个标识符、改变程序代码的时序 关系、改变占用存储的大小、改变逻辑运算符、修改文件的打开或关闭、改进程序的执行效 率,以及把设计上的改变翻译成代码的改变、为边界条件的逻辑测试做出改变时,都容易引 入错误 ■修改数据的副作用。在修改数据结构时,有可能造成软件设计与数据结构不匹配,因 而导致软件出错。数据副作用就是修改软件信息结构导致的结果。例如,在重新定义局部的 或全局的常量、重新定义记录或文件的格式、增大或减小一个数组或高层数据结构的大小 修改全局或公共数据、重新初始化控制标志或指针、重新排列输入/输出或子程序的参数时, 容易导致设计与数据不相容的错误。数据副作用可以通过详细的设计文档加以控制。在此文 档中描述了一种交叉引用,把数据元素、记录、文件和其它结构联系起来 文档的副作用。对数据流、软件结构、模块逻辑或任何其它有关特性进行修改时, 必须对相关技术文档进行相应修改。否则会导致文档与程序功能不匹配,缺省条件改变,新 错误信息不正确等错误。使得软件文档不能反映软件的当前状态。对于用户来说,软件事实 上就是文档。如果对可执行软件的修改不反映在文档里,就会产生文档的副作用。例如,对 交互输入的顺序或格式进行修改,如果没有正确地记入文档中,就可能引起重大的问题。过 时的文档内容、索引和文本可能造成冲突,引起用户的失败和不满。因此,必须在软件交付 之前对整个软件配置进行评审,以减少文档的副作用。 为了控制因修改而引起的副作用,要做到: i)按模块把修改分组 ⅱ)自顶向下地安排被修改模块的顺序: ⅲi)每次修改一个模块; iv)对于每个修改了的模块,在安排修改下一个模块之前,要确定这个修改的副作用 可以使用交叉引用表、存储映象表、执行流程跟踪等。 (3)重新验证程序 在将修改后的程序提交用户之前,需要用以下的方法进行充分的确认和测试,以保证整 个修改后的程序的正确性 ①静态确认 修改软件,伴随着引起新的错误的危险。为了能够做出正确的判断,验证修改后的程序 至少需要两个人参加。要检查 ■修改是否涉及到规格说眀?修改结果是否符合规格说明?有没有歪曲规格说明? 程序的修改是否足以修正软件中的问题?源程序代码有无逻辑错误?修改时有无修补 失误?10 的问题。 ② 修改代码，以适应变化 ▪ 正确、有效地编写修改代码； ▪ 要谨慎地修改程序，尽量保持程序的风格及格式，要在程序清单上注明改动的指令； ▪ 不要删除程序语句，除非完全肯定它是无用的； ▪ 不要试图共用程序中已有的临时变量或工作区，为了避免冲突或混淆用途，应自行设 置自己的变量； ▪ 插入错误检测语句； ▪ 在修改过程中做好修改的详细记录，消除变更中任何有害的副作用(波动效应）； ③ 修改程序的副作用 所谓副作用是指因修改软件而造成的错误或其它不希望发生的情况，有三种副作用： ▪ 修改代码的副作用。在使用程序设计语言修改源代码时，都可能引入错误。例如，删 除或修改一个子程序、删除或修改一个标号、 删除或修改一个标识符、改变程序代码的时序 关系、改变占用存储的大小、改变逻辑运算符、修改文件的打开或关闭、改进程序的执行效 率，以及把设计上的改变翻译成代码的改变、为边界条件的逻辑测试做出改变时，都容易引 入错误。 ▪ 修改数据的副作用。在修改数据结构时，有可能造成软件设计与数据结构不匹配，因 而导致软件出错。数据副作用就是修改软件信息结构导致的结果。例如，在重新定义局部的 或全局的常量、 重新定义记录或文件的格式、增大或减小一个数组或高层数据结构的大小、 修改全局或公共数据、重新初始化控制标志或指针、重新排列输入／输出或子程序的参数时， 容易导致设计与数据不相容的错误。数据副作用可以通过详细的设计文档加以控制。在此文 档中描述了一种交叉引用，把数据元素、记录、文件和其它结构联系起来。 ▪ 文档的副作用。对数据流、软件结构、 模块逻辑或任何其它有关特性进行修改时， 必须对相关技术文档进行相应修改。否则会导致文档与程序功能不匹配，缺省条件改变，新 错误信息不正确等错误。使得软件文档不能反映软件的当前状态。对于用户来说，软件事实 上就是文档。如果对可执行软件的修改不反映在文档里，就会产生文档的副作用。例如，对 交互输入的顺序或格式进行修改，如果没有正确地记入文档中，就可能引起重大的问题。过 时的文档内容、索引和文本可能造成冲突，引起用户的失败和不满。因此，必须在软件交付 之前对整个软件配置进行评审，以减少文档的副作用。 为了控制因修改而引起的副作用，要做到： ⅰ) 按模块把修改分组； ⅱ) 自顶向下地安排被修改模块的顺序； ⅲ) 每次修改一个模块； ⅳ) 对于每个修改了的模块，在安排修改下一个模块之前，要确定这个修改的副作用。 可以使用交叉引用表、存储映象表、执行流程跟踪等。 (3) 重新验证程序 在将修改后的程序提交用户之前，需要用以下的方法进行充分的确认和测试，以保证整 个修改后的程序的正确性。 ① 静态确认 修改软件，伴随着引起新的错误的危险。为了能够做出正确的判断，验证修改后的程序 至少需要两个人参加。要检查 ▪ 修改是否涉及到规格说明? 修改结果是否符合规格说明? 有没有歪曲规格说明? ▪ 程序的修改是否足以修正软件中的问题? 源程序代码有无逻辑错误? 修改时有无修补 失误?