第八章 软件维护解析.ppt

* 2．修改代码，以适应变化 （1）正确、有效地编写修改代码； （2）要谨慎地修改程序，尽量保持程序的风格及格式，要在程序清单上注明改动的指令； （3）不要匆忙删除程序语句，除非完全肯定它是无用的； （4）不要试图共用程序中已有的临时变量或工作区，为了 避免冲突或混淆用途，应自行设置自己的变量； （5）插入错误检测语句； （6）保持详细的维护活动和维护结果记录； （7）如果程序结构混乱，修改受到干扰，可抛弃程序重新 编写。 8.3 程序修改的步骤及修改的副作用 所谓程序修改的副作用是指因修改软件而造成的错误 或其他不希望发生的情况，有以下3种副作用： 1．修改代码的副作用 在使用程序设计语言修改源代码时，都可能引入新的 错误。例如，删除或修改一个子程序、删除或修改一个标 号、删除或修改一个标识符、改变程序代码的时序关系、 改变占用存储的大小、改变逻辑运算符、修改文件的打开 或关闭、改进程序的执行效率，以及把设计上的改变翻译 成代码的改变、为边界条件的逻辑测试做出改变时，都容 易引入错误。 8.3 程序修改的步骤及修改的副作用 修改程序的副作用及其控制 2．修改数据的副作用 在修改数据结构时，有可能造成软件设计与数据结构不匹 配，因而导致软件出错。修改数据的副作用是修改软件信息 结构导致的结果。例如，在重新定义局部的或全局的常量、 重新定义记录或文件的格式、增大或减小一个数组或高层数 据结构的大小、修改全局或公共数据、重新初始化控制标志 或指针、重新排列输入/输出或子程序的参数时，容易导致 设计与数据不相容的错误。数据副作用可以通过详细的设计 文档加以控制。 8.3 程序修改的步骤及修改的副作用 3．修改文档的副作用 对数据流、软件结构、模块逻辑或任何其他有关特性进 行修改时，必须对相关技术文档进行相应修改。如果对可 执行软件的修改不反映在文档里，会产生文档的副作用。 例如，对交互输入的顺序或格式进行修改，如果没有正确 地记入文档中，可能引起重大的问题。过时的文档内容、 索引和文本可能造成冲突，引起用户业务的失败和不满。 因此，必须在软件交付之前对整个软件配置进行评审，以 减少文档的副作用。 8.3 程序修改的步骤及修改的副作用 为了控制因修改而引起的副作用，要做到： （1）按模块把修改分组； （2）自顶向下地安排被修改模块的顺序； （3）每次修改一个模块； （4）对于每个修改了的模块，在安排修改下一个模块之 前，要确定这个修改的副作用，可以使用交叉引用 表、存储映象表、执行流程跟踪等。 8.3 程序修改的步骤及修改的副作用 1．静态确认 修改的软件，通常伴随着引起新的错误的危险。为了能够 做出正确的判定，验证修改后的程序至少需要两个人参加。 要检查： （1）修改是否涉及规格说明？修改结果是否符合规格说 明？有没有歪曲规格说明？ （2）程序的修改是否足以修正软件中的问题？源程序代码 有无逻辑错误？修改时有无修补失误？ （3）修改部分对其他部分有无不良影响（副作用）？ 对软件进行修改，常常会引发别的问题，因此，有必要 检查修改的影响范围。 重新验证程序 8.3 程序修改的步骤及修改的副作用 2．确认测试 在充分进行了以上确认的基础上，要用计算机对修改程 序进行确认测试。 （1）确认测试顺序：先对修改部分进行测试，然后隔离修 改部分，测试程序的未修改部分，最后再把它们集成起 来进行测试。这种测试称为回归测试。 （2）准备标准的测试用例。 （3）充分利用软件工具帮助重新验证过程。 （4）在重新确认过程中，需邀请用户参加。 8.3 程序修改的步骤及修改的副作用 3．维护后的验收 在交付新软件之前，维护主管部门要检验： （1）全部文档是否完备，并已更新； （2）所有测试用例和测试结果已经正确记载； （3）记录软件配置所有副本的工作已经完成； （4）维护工序和责任是明确的。 8.3 程序修改的步骤及修改的副作用 软件维护性是指当对软件实施各种类型的维护而进行修改时，软件产品可被修改的能力。 软件维护的子特性： 8.4 软件的维护性 软件维护性的定义 8.4 软件的维护性 软件维护性度量的任务是对软件产品的维护性给出量化的评价。 软件维护的度量也分为内部维护性度量和外部维护性度量，两者的差别如下表。 1．模块化 模块化技术的优点是如果需要改变某个模块的功能，则 只要改变这个模块，对其他模块影响很小；如果需要增加 程序的某些功能，则仅需增加完成这些功能的新的模块或 模块层；程序的测试与重