第十章软件维护要点解析.pptVIP

在每次软件维护任务完成后进行情况评审，对以下问题做一总结： 在目前情况下，设计、编码、测试中的哪一方面可以改进? 哪些维护资源应该有但没有? 工作中主要的或次要的障碍是什么? 从维护申请的类型来看是否应当有预防性维护? 情况评审对将来的维护工作如何进行会产生重要的影响。 4. 维护评价 评价维护活动比较困难，因为缺乏可靠的数据。 如果维护的档案记录做得比较好，可以得出一些维护绩效方面的度量值。 每次程序运行时的平均出错次数； 花费在每类维护上的总“人时”数； 每个程序、每种语言、每种维护类型的程序平均修改次数； 因为维护，增加或删除每个源程序语句所花费的平均“人时”数； 用于每种语言的平均“人时”数； 维护申请报告的平均处理时间； 各类维护申请的百分比。 据此可对开发技术、语言选择、维护工作计划、资源分配、以及其它许多方面做出判定。 10.3 程序修改的步骤及修改的副作用 在软件维护时必然会对源程序进行修改。 通常对源程序的修改不能无计划地仓促上阵，为了正确、有效地修改，需要经历以下三个步骤。 分析和理解程序 修改程序 重新验证程序 1. 分析和理解程序 经过分析，全面、准确、迅速地理解程序是决定维护成败和质量好坏的关键。在这方面，软件的可理解性和文档的质量非常重要。 理解程序的功能和目标； 掌握程序的结构信息, 即从程序中细分出若干结构成分。如程序系统结构、 控制结构、数据结构和输入／输出结构等； 了解数据流信息，即涉及到的数据来源何处，在哪里被使用；  了解控制流信息，即执行每条路径的结果； 理解程序的操作（使用）要求； 为了容易地理解程序，要求自顶向下地理解现有源程序的程序结构和数据结构，为此可采用如下几种方法： 分析程序结构图 搜集所有存储该程序的文件，阅读这些文件，记下它们包含的过程名，建立包括这些过程名和文件名的清单； 分析各个过程的源代码，建立一个直接调用矩阵D或调用树。若过程i调用过程j，则D[i][j]＝1，否则D[i][j]＝0。 建立过程的间接调用矩阵I，即直接调用矩阵D的传递闭包 I＝D1∪D2∪D3∪…∪Dn 其中，n是所包含的过程总数. 分析各过程的接口，估计更改复杂性。 数据跟踪 建立各层次程序级上的接口图, 展示各模块或过程的调用方式和接口参数； 利用数据流分析方法，对过程内部的一些变量进行跟踪。可获得有关数据在过程间如何传递，在过程内如何处理等信息。对于判断问题原因特别有用。 在跟踪的过程中可在源程序中间插入自己的注释。 (3) 控制跟踪 控制流跟踪可采用符号执行或实际动态跟踪的方法，了解数据如何从一个输入源到达输出点的。 充分阅读和使用源程序清单和文档，分析现有文档的合理性。 充分使用由编译程序或汇编程序提供的交叉引用表、符号表、以及其它有用的信息。 如有可能，积极参加开发工作。 软件工程 * 2. 修改程序 对程序的修改，必须事先做出计划，有预谋地、周密有效地实施修改。 设计程序的修改计划 制定程序的修改计划要考虑人员和资源的安排。 小的修改可以不需要详细的计划，而对于需要耗时数月的修改，就需要计划立案。 在编写有关问题解决的方案时，必须充分描述修改作业的规格说明。包括： 规格说明信息：数据修改、处理修改、作业控制语言修改、系统之间接口的修改等； 维护资源：新程序版本、测试数据、所需软件、计算机时间等； 人员； 支持：纸面、计算机媒体等。 通常，可采用自顶向下的方法，在理解程序的基础上， 研究程序的各个模块、模块的接口、及数据库，从全局的观点，提出修改计划。 依次把要修改的以及受修改影响的模块和数据结构分离出来。为此，要求 识别受修改影响的数据； 识别使用这些数据的程序模块； 对于这些程序模块，按是产生数据、修改数据、还是删除数据进行分类； 识别这些数据的外部控制信息; 识别编辑和检查这些数据的地方； 隔离要修改的部分； 详细地分析要修改的、以及那些受变更影响的模块和数据结构的内部细节，设计修改计划，标明新逻辑及要改动的现有逻辑。 向用户提供回避措施。用户的某些业务因软件中发生问题而中断，为不让系统长时间停止运行，需把问题局部化，在可能的范围内继续开展业务。 可以采取的措施有： ① 查找问题原因，可能情况有： 软件工程 * 意外停机 安装的期限到期 系统运行中发现错误 ② 如果弄清了问题的原因, 可通过临时修改或改变运行控制以回避在系统运行时产生的问题。 修改代码，以适应变化 在修改时，要求： 正确、有效地编写修改代码； 要谨慎地修改程序, 尽量保持程序的风格及格式, 要在程序清单上注明改动的指令； 不要删除程序语句，除非完全肯定它是无用的； 不要试图共用程序中已有的临时变量或工作区，应设置自己的变量； 插入错误检测