软件工程第12章 软件维护.pptVIP

评价维护活动可参考的度量值有： ● 每次程序运行时的平均出错次数； ● 花费在每类维护上的总“人时”数； ● 每个程序、每种语言、每种维护类型的程序平均修改次 数； ● 因为维护，增加或删除每个源程序语句所花费的平均“人 时”数； ● 用于每种语言的平均“人时”数； ● 维护申请报告的平均处理时间； ● 各类维护申请的百分比。 12.2 软件维护活动 维护评价 为了正确、有效地进行程序修改，需要经历3个步骤：分 析和理解程序、实施修改以及重新验证程序。 12.3 程序修改的步骤及修改的副作用 分析和理解程序 经过分析，全面、准确、迅速地理解程序是决定维护成 败和质量好坏的关键。在这方面，软件的可理解性和文档的 质量非常重要。为此必须： （1）研究程序的使用环境及有关资料，尽可能得到更多的 背景信息； （2）理解程序的功能和目标； （3）掌握程序的结构信息，即从程序中细分出若干结构成 分，如程序系统结构、控制结构、数据结构和输入/输 出结构等； （4）了解数据流信息，即所涉及的数据来自何处，在哪里 被使用； （5）了解控制流信息，即执行每条路径的结果； （6）如果设计存在，则可利用它们来帮助画出结构图和高 层流程图； （7）理解程序的操作（使用）要求。 12.3 程序修改的步骤及修改的副作用 为了容易地理解程序，要求自顶向下地理解现有源程序的 程序结构和数据结构，为此可采用如下几种方法。 （1）分析程序结构图。 （2）数据跟踪。 （3）控制跟踪。可采用符号执行或实际动态跟踪的方法， 了解数据是如何从一个输入源到达输出点的。 （4）在分析的过程中，应充分阅读和使用源程序清单和文 档，分析现有文档的合理性。 （5）充分使用由编译程序或汇编程序提供的交叉引用表、 符号表，以及其他有用的信息。 （6）如有可能，争取参加开发工作。 12.3 程序修改的步骤及修改的副作用 对程序的修改，必须事先做出计划，有准备地、周密有效 地实施修改。 1．设计程序的修改计划 程序的修改计划要考虑人员和资源的安排。修改计划的内 容主要包括以下几项： （1）规格说明信息：数据修改、处理修改、作业控制语言 修改、系统之间接口的修改等。 （2）维护资源：新程序版本、测试数据、所需的软件系 统、计算机时间等。 12.3 程序修改的步骤及修改的副作用 修改程序 （3）人员：程序员、用户相关人员、技术支持人员、厂家 联系人、数据录入员等。 （4）提供：纸质、计算机媒体等。 针对以上每一项，要说明必要性、从何处着手、是否接 受、日期等。通常，可采用自顶向下的方法，在理解程序的 基础上做如下工作： （1）研究程序的各个模块、模块的接口及数据库，从全局 的观点提出修改计划。 （2）依次把要修改的、以及那些受修改影响的模块和数据 结构分离出来。 12.3 程序修改的步骤及修改的副作用 （3）详细地分析要修改的，以及那些受变更影响的模块和 数据结构的内部细节，设计修改计划，标明新逻辑及 要改动的现有逻辑。 （4）向用户提供回避措施。用户的某些业务因软件中发生 问题而中断，为不让系统长时间停止运行，需把问题 局部化，在可能的范围内继续开展业务。 2．修改代码，以适应变化 修改时，要求： （1）正确、有效地编写修改代码； （2）要谨慎地修改程序，尽量保持程序的风格及格式，要 12.3 程序修改的步骤及修改的副作用 在程序清单上注明改动的指令； （3）不要匆忙删除程序语句，除非完全肯定它是无用的； （4）不要试图共用程序中已有的临时变量或工作区，为了 避免冲突或混淆用途，应自行设置自己的变量； （5）插入错误检测语句； （6）保持详细的维护活动和维护结果记录； （7）如果程序结构混乱，修改受到干扰，可抛弃程序重新 编写。 12.3 程序修改的步骤及修改的副作用 所谓程序修改的副作用是指因修改软件而造成的错误 或其他不希望发生的情况，有以下3种副作用： 1．修改代码的副作用 在使用程序设计语言修改源代码时，都可能引入新的 错误。例如，删除或修改一个子程序、删除或修改一个标 号、删除或修改一个标识符、改变程序代码的时序关系、 改变占用存储的大小、改变逻辑运算符、修改文件的打开 或