第8章+软件维护.ppt

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