软件工程讲稿12.ppt

第十一章 软件维护 1.软件维护的定义 2.软件维护的特点 3.软件维护过程 4.软件的可维护性 5.预防性维护 6.软件再工程过程 第十一章 软件维护 用户通常根据描述软件特点和使用方法的用户文档来使用、评价软件。如果对软件的可执行部分的修改没有及时反映在用户文档中，则必然会使用户因为受挫折而产生不满。 如果在软件再次交付使用之前，对软件配置进行严格的复审，则可大大减少文档的问题。事实上，某些维护要求可能并不需要修改软件设计或源程序代码，只是表明用户文档不清楚或不准确，因此只需要对文档做必要的维护。 几乎所有历史比较悠久的软件开发组织，都有一些十几年前开发出的“老”程序。目前，某些老程序仍然在为用户服务，但是，当初开发这些程序时并没有使用软件工程方法学来指导，因此，这些程序的体系结构和数据结构都很差，文档不全甚至完全没有文档，对曾经做过的修改也没有完整的记录。 怎样满足用户对上述这类老程序的维护要求呢？为了修改这类程序以适应用户新的或变更的需求，有以下几种做法可供选择： 第十一章 软件维护 5. 预防性维护 ① 反复多次地做修改程序的尝试，与不可见的设计及源代码“顽强战斗”，以实现所要求的修改； ② 通过仔细分析程序尽可能多地掌握程序的内部工作细节，以便更有效地修改它； ③ 在深入理解原有设计的基础上，用软件工程方法重新设计、重新编码和测试那些需要变更的软件部分； 第十一章 软件维护 ④ 以软件工程方法学为指导，对程序全部重新设计、重新编码和测试，为此可以使用CASE工具（逆向工程和再工程工具）来帮助理解原有的设计。 第一种做法很盲目，人们通常采用后3种做法，其中第④种做法称为软件再工程，这样的维护活动也就是预防性维护，而第③种做法实质上是局部的再工程。 预防性维护方法是由Miller提出来的，他把这种方法定义为：“把今天的方法学应用到昨天的系统上，以支持明天的需求。” 第十一章 软件维护 粗看起来，在一个正在工作的程序版本已经存在的情况下，重新开发一个大型程序，似乎是一种浪费。其实不然，下述事实很能说明问题： ① 维护一行源代码的代价可能是最初开发时的代价的14~40倍； ② 重新设计软件体系结构(程序及数据结构)时使用了现代设计 概念，它对将来的维护可能有很大的帮助； ③ 由于现有的程序版本可作为软件原型使用，开发生产率可大 大高于平均水平； ④ 用户具有较多使用该软件的经验，因此，能够很容易地搞清 新的变更需求和变更的范围； ⑤ 利用逆向工程和再工程的工具，可以使一部分工作自动化； ⑥ 在完成预防性维护的过程中可以建立起完整的软件配置。 典型的软件再工程过程模型如图所示。 第十一章 软件维护 6. 软件再工程过程 该模型定义了6类活动。在某些情况下，这些活动以线性顺序发生，但也并非总这样。例如，为了理解某个程序的内部工作原理，可能在文档重构之前必须先进行逆向工程。 如图所示的再工程范型是一个循环模型，这意味着作为该范型的组成部分的每个活动都可能被重复，且对于任意一个特定的循环来说，过程可以在完成任意一个活动之后终止。 第十一章 软件维护 (1) 库存目录分析 每个软件组织都应该保存其拥有的所有应用系统的库存目录。该目录包含关于每个应用系统的基本信息(如应用系统的名字、最初构建它的日期、已做过的实质性修改次数、过去18个月报告的错误、用户数量、安装它的机器数量、它的复杂程度、文档质量、整体可维护性等级、预期寿命、在未来36个月内的预期修改次数、业务重要程度等)。 每一个大的软件开发机构都拥有上百万行老代码，它们都可能是逆向工程或再工程的对象。但是，某些程序可能并不频繁使用而且不需要改变。此外，逆向工程和再工程工具尚不成熟，目前仅能对有限种类的应用系统执行逆向工程或再工程，代价又十分高昂，因此，对库中每个程序都做逆向工程或再工程是不现实的。 第十一章 软件维护 下述3类程序有可能成为预防性维护的对象： ① 预定将使用多年的程序； ② 当前正在成功地使用着的程序； ③ 在最近的将来可能要做重大修改或增强的程序。 应该仔细分析库存目录，按照业务重要程度、寿命、当前可维护性、预期的修改次数等标准，把库中的应用系统排序，从中选出再工程的候选者，然后明智地分配再工程所需要的资源。 第十一章 软件维护 (2) 文档重构 老程序固有的特点是缺乏文档。具体情况不同，处理这个问题的方法也不同： ① 建立文档是非常耗费时间，也不可能为数百个程序都重新建立