第8章 软件维护.ppt

* 1. 用户文档 用户文档是用户了解系统的第一步，它应该能使用户获得对系统的准确的初步印象。文档的结构方式应该使用户能够方便地根据需要阅读有关的内容。 用户文档至少应该包括下述5方面的内容： (1) 功能描述； (2) 安装文档； (3) 使用手册； (4) 参考手册； (5) 操作员指南(如果需要有系统操作员的话) 。 上述内容可以分别作为独立的文档， 也可以作为一个文档的不同分册， 具体做法应该由系统规模决定。 * 2. 系统文档 ---- 所谓系统文档指从问题定义、需求说明到验收测试计划这样一系列和系统实现有关的文档。 ---- 描述系统设计、实现和测试的文档对于理解程序和维护程序来说是极端重要的。 ---- 和用户文档类似，系统文档的结构也应该能把读者从对系统概貌的了解，引导到对系统每个方面每个特点的更形式化更具体的认识。 * 8.4.3 提高可维护性的方法 建立明确的软件质量目标和优先级 使用提高软件质量的技术和工具 进行明确的质量保证审查 选择可维护的程序设计语言 改进程序的文档 * 8.4.4 可维护性复审 在软件工程过程的每一个阶段都应该考虑并努力提高软件的可维护性，在每个阶段结束前的技术审查和管理复审中，应该着重对可维护性进行复审。 * 在完成了每项维护工作之后，都应该对软件维护本身进行仔细认真的复审。 --- 维护应该针对整个软件配置，不应该只修改源程序代码。当对源程序代码的修改没有反映在设计文档或用户手册中时，就会产生严重的后果。 --- 每当对数据、软件结构、模块过程或任何其他有关的软件特点做了改动时，必须立即修改相应的技术文档。不能准确反映软件当前状态的设计文档可能比完全没有文档更坏。 --- 用户通常根据描述软件特点和使用方法的用户文档来使用、评价软件。如果对软件的可执行部分的修改没有及时反映在用户文档中，则必然会使用户因为受挫折而产生不满。 * 8.5 预防性维护 预防性维护方法是由Miller提出来的，他把这种方法定义为：“把今天的方法学应用到昨天的系统上，以支持明天的需求。” 开发和维护者不应等待用户的维护申请,在条件具备时应该主动地进行预防性维护。 预防性维护对象: 预计若干年内将继续使用的程序 当今正成功使用的程序 最近的将来要进行大修改和完善的程序 再工程是一个重构活动（类比 重建一所房子） 开始重建前，首先检查一下房子。确定它是否确实需要重建？ 在拆掉并重建房子前，确定其结构是否牢固。若结构良好，则可能是“改造”。 在开始重建前，确保你已经了解房子最初是如何建造的。（墙内部，了解布线、管道以及内部结构。） 如果开始重建，应该使用最现代的，耐久的材料。 如果决定重建，一定要采用严格的方式，使用现在及将来都将获得高质量的做法。 8.6 软件再工程过程（Software Reengineering） * 8.6 软件再工程过程 （Software Reengineering） 软件再工程过程模型 软件再工程是一类软件工程活动，是一个工程过程, 它将逆向工程、重构和正向工程组合起来,将现存系统重新构造为新的形式。 * 软件再工程过程示意图 需求 新需求 设计 设计 代码 代码 正 向 工 程 逆 向 工 程 （重构） （重构） （重构） * 软件再工程过程模型所定义的6类活动 1. 库存目录分析 2. 文档重构 3. 逆向工程 4. 代码重构 5. 数据重构 6. 正向工程 本章小结 软件维护的4类活动 （改正性、适应性、完善性、预防性） 决定软件可维护性的基本要素 （可理解、可测试、可修改、可移植和可重用性） 文档是影响软件可维护性的决定因素 软件再工程（预防性维护） * 对于用户来说，软件事实上就是文档。 * 1. 可理解性 软件可理解性 诊断和测试的容易程度取决于软件容易理解的程度。良好的文档对诊断和测试是至关重要的，此外，软件结构、可用的测试工具和调试工具，以及以前设计的测试过程也都是非常重要的。维护人员应该能够得到在开发阶段用过的测试方案，以便进行回归测试。在设计阶段应该尽力把软件设计成容易测试和容易诊断的。 对于程序模块来说，可以用程序复杂度来度量它的可测试性。模块的环形复杂度越大，可执行的路径就越多，因此，全面测试它的难度就越高。 3. 可修改性 软件容易修改的程度和本书第5章讲过的设计原理和启发规则直接有关。耦合、内聚、信息隐藏、局部化、控制域与作用域的关系等等，都影响软件的可修改性。 4. 可移植性 软件可移植性指的是，把程序从一种计算环境（硬件配置和操作系统）转移到另一种计算环境的难易程度