软件工程部分6汇编.ppt

三十年以前，软件维护（maintenance）被刻画为冰山。在20世纪70年代的早期，维护冰山非常大，足以使一艘航空母舰沉没。而今天，它已可以很容易的沉没整个海军！ 现在软件开发机构要把70%的工作量用在维护巳有的软件上。随着软件产品的增加，这个百分比还会提高！ 这是因为我们主要依赖的软件已15年到20年的使用史。即使这些程序的创建是采用当时最好的设计和最好的编码技术（大多数并非如此） ，它们创建时的主要关注点却是程序的规模和存储空间（因为当时的主要矛盾是机器的运算速度太慢和存储空间太小）。然后，它们被移植到新的平台上，只是根据机器和操作系统技术方面的变化进行调整，并根据用户的需求作了增加。所有这些，并没有对软件的整个体系结枸给予足够的关注和改进。实际情况是：我们仍然保持运行的软件，具有设计很差的结构、糟糕的编码、很差的逻辑和不完整的文档 计算机软件不断修改是不可避免的，这是软件的基本特性。因此，我们必须建立某些管理机制，来评价、控制和完成这些修改 6.4 软件的可维护性 软件可维护性可以定性地定义为：维护人员理解、改正、适应和完善软件，以适应新的环境的难易程度。因此，我们始终要强调的是：要在软件工程的各个步骤中，提高软件的可维护性是一个关键目标。 6.4.1 决定软件可维护性的因素 维护就是在软件交付使用后进行的修改，修改之前必须理解修改的对象，修改之后应该进行必要的测试，以保证所做的修改是正确的。如果是改正性维护，还必须预先进行调试以确定错误。因此，影响软件可维护性的因素主要有下述五个：、 1. 可理解性 2. 可测试性 3. 可修改性 4. 可移植性 5. 可重用性 6.4.2 文档 文档是影响软件可维护性的决定因素。由于长期使用的大型软件系统在使用过程中必然会经受多次修改，所以文档比程序代码更重要。 软件系统的文档可以分为用户文档和系统文档两类。用户文档主要描述系统功能和使用方法，并不关心这些功能是怎样实现的；系统文档描述系统设计、实现和测试等各方面的内容。 总的说来，软件文档应该满足下述要求： （1）必须描述如何使用这个系统，没有这种描述即使是最简单的系统也无法使用； （2）必须描述怎样安装和管理这个系统； （3）必须描述系统需求和设计； （4）必须描述系统的实现和测试，以便使系统成为可维护的。 下面分别讨论用户文档和系统文档： 1. 用户文档 用户文档是用户了解系统的第一步，它应该能使用户获得对系统的准确的初步印象。文档的结构方式应该使用户能够方便地根据需要阅读有关的内容。 用户文档至少应该包括下述五方面的内容： （1）功能描述——说明系统能做什么； （2）安装文档——说明怎样安装这个系统以及怎样使系统适应特定的硬件配置； （3）使用手册——简要说明如何着手使用这个系统（应该通过丰富例子说明怎样使用常用的系统功能，还应该说明用户操作错误时怎样恢复和重新启动）； （4）参考手册——详尽描述用户可以使用的所有系统设施以及它们的使用方法，还应该解释系统可能产生的各种出错信息的含义（对参考手册最主要的要求是完整，因此通常使用形式化的描述技术）； （5）操作员指南（如果需要有系统操作员的话）——说明操作员应该如何处理使用中出现的各种情况。 上述内容可以分别作为独立的文档，也可以作为一个文档的不同分册，具体做法应该由系统规模决定。 2. 系统文档 所谓系统文档指从问题定义、需求说明到验收测试计划这样一系列和系统实现有关的文档。描述系统设计、实现和测试的文档对于理解程序和维护程序来说是极端重要的。和用户文档类似，系统文档的结构也应该能把读者从对系统概貌的了解，引导到对系统每个方面每个特点的更形式化更具体的认识。 6.4.3 可维护性复审 可维护性是所有软件都应该具备的基本特点，必须在开发阶段保证软件具有6.4.1节中提到的那些可维护因素。在软件工程过程的每一个阶段都应该考虑并努力提高软件的可维护性，在每个阶段结束前的技术审查和管理复审中，应该着重对可维护性进行复审。 6.5 预防性维护 预防性维护也称为软件再工程。目前，在全部软件维护活动中，预防性维护只占很小的比例。多数软件维护人员对预防性维护还缺乏足够的了解。本节说明进行预防性维护的必要性和可行性，下一节讲述软件再工程的典型过程。 6.5.1 必要性 预防性维护方法是Miller在“结构化翻新”的标题下提出来的，他把这个概念定义为“把今天的方法学应用到昨天的系统以支持明天的需求”。 * * 第6章 软件维护 软件工程部分： 6.1 软件维护的定义与策略 6.2 软件维护的特点 6.3 软件维护过程 6.4 软件的可维护性 6.5