第9章软件进化

1、第9章 软件进化2本章引导本章旨在解释为什么软件进化是软件工程中一个重要组成部本章旨在解释为什么软件进化是软件工程中一个重要组成部分分,讲解软件进化过程。本章主要内容讲解软件进化过程。本章主要内容:了解变更是不可避免的。如果要使软件系统继续有用了解变更是不可避免的。如果要使软件系统继续有用,那么软那么软件开发和软件进化将集成在螺旋模型中。件开发和软件进化将集成在螺旋模型中。了解软件进化过程以及作用于这些过程上的因素。了解软件进化过程以及作用于这些过程上的因素。学习不同类型的软件维护和影响维护费用的因素。学习不同类型的软件维护和影响维护费用的因素。了解如何对遗留系统进行评估，从而决定是应该抛弃、

2、维护、了解如何对遗留系统进行评估，从而决定是应该抛弃、维护、再工程还是更换这些系统。再工程还是更换这些系统。3软件变更是不可避免的软件变更是不可避免的软件在使用过程中，新的需求不断出现软件在使用过程中，新的需求不断出现商业环境在不断地变化商业环境在不断地变化软件中的缺陷需要进行修复软件中的缺陷需要进行修复计算机硬件和软件环境的升级需要更新现有的系统计算机硬件和软件环境的升级需要更新现有的系统软件的性能和可靠性需要进一步改进软件的性能和可靠性需要进一步改进。4开发和进化的螺旋模型软件过程是一个贯穿系统生命周期的由需求、设计、实现、测试组成的螺旋过程。59.1进化过程 变更实现的过程看成是一个开发

3、过程的迭代过程，在此迭代过程中完成对系统修改版本的设计、实现和测试。6软件进化过程 Arthur(1988)7考虑：敏捷方法团队对“过程驱动方法团队”的软件进化时遇到的问题。这种情况下，进化团队可能不得不从头开发自动化的测试，而且不会有像敏捷开发过程中所期待的系统代码重构和简化。这样，在采用敏捷开发过程之前,可能要求使用一些再工程方法来提升其代码质量。8考虑：过程驱动方法团队对“敏捷方法团队”的软件进化时遇到的问题。开发团队运用了敏捷方法,但是进化团队却不熟悉敏捷方法而选择了一个计划驱动的方法。进化团队可能期望详细的文档来支持进化工作的进行，而这恰恰是敏捷方法所没有提供的。可能没有关于系统的一

4、个明确的描述以供变更时使用。99.2 程序进化的动态特性程序进化的动态特性就是对系统变更的研究。20实际90年代，Lehman和其他人开始研究进化过程中反馈的重要性。10Lehman定律第1条定律:系统维护是一个不可避免的过程。当系统的环境发生改变，新的需求就会出现，系统就必须修改。第2条定律:随着系统的改变，其结构在退化。加强预防性维护工作。第5条定律：向系统中添加新功能不可避免。但会把新的缺陷引人到系统中。在每个版本中增加的功能愈多,缺陷将会愈多。请阅读Lehman定律（P153）119.3 软件维护与变更软件被投入运行使用后人们对软件产品所进行的修改，就是软件维护。维护的类型：改正性维护

5、：修改软件中的缺陷或不足适应性维护：修改软件使其适应不同的操作环境，包括硬件变化、操作系统变化或者其他支持软件变化等完善性维护：增加或修改系统的功能，使其适应业务的变化12软件维护工作量分布13软件维护的成本尽管软件技术在进步，修改软件经验在积累，可是自从 世纪80年代以来，在进化方面投入的百分比很少有改变。软件维护的成本在不同的应用领域中占比不同业务应用系统：维护费用与开发成本大体相同嵌入式实时系统：维护费用是开发成本的四倍以上。因为高可靠性和高性能需求使得模块间紧密连接，修改起来非常困难。14开发和维护的成本系统1（相比系统2） 在开发中多投入25000美元，整个生命周期节省了100000

6、美元，表明在开发成本上增加一个百分数，在总的生命周期成本中会下降相应的百分数。15影响维护成本的因素1 团队稳定性系统移交后开发团队会解散，人员分配到其他项目中，负责维护的人员通常不是原开发人员，需要花时间理解系统。2 合同责任维护合同一般独立于开发合同，这样开发人员有可能缺少为方便维护而写软件的动力。3 人员技术水平维护人员有可能缺乏经验，而且不熟悉应用领域。4 程序年龄与结构程序结构随年龄的增加而受到破坏，不易理解和变更。169.3.1 软件维护预测 管理者憎恨意外的发生,尤其是那些造成了意想不到的高成本的意外。因此，有必要预测系统会有什么样的变更、系统的哪些部分可能是最难维护的等。17预

7、测系统变更预测变更请求数目应了解系统和外部环境之间的关系许多系统与外部环境之间存在着复杂的关系，对环境所做的改变不可避免地导致系统变更的发生变更预测的影响因素系统接口的数目和复杂性本质上易变的系统需求的数目系统所处的业务过程18预测可维护性和维护成本需要了解在系统不同组件和这些组件的固有复杂性之间的关系类型和关系数目，系统或组件越复杂，其维护费用就越高。复杂性依赖于控制结构的复杂性数据结构的复杂性对象、方法和模块大小199.3.2 软件再工程软件再工程是指软件重新构造或编写现有系统的一部分或全部，但不改变其功能。在大型系统中某些部分需要频繁维护时，可应用软件再工程软件再工程的目的是努力使系统更

8、加易于维护，系统需要被再构造和再文档化20软件再工程优势及缺点减少风险：重新开发一个在用的系统具有很高的风险，可能会有开发问题、人员问题和规格说明问题降低成本：再工程的成本比重新开发软件的成本要小得多软件再工程的缺点是系统经过再工程能改善的范围受到一定的限制。21正向工程与再工程22再工程活动23再工程活动1.源代码转换代码从原有的程序设计语言转换到一种新语言2.逆向工程分析程序并抽取信息记录其结构和功能3.程序结构改善分析和修改程序的控制结构，使其更易读和好理解4.程序模块化重新组织程序的结构5.数据再工程改变程序处理的数据以反映程序的变更，这可能意味着重新定义数据库模式和将已存在的数据库向

9、新的结构转变。249.3.3 通过重构进行预防性维护 重构是提升程序以减缓其由于更改而退化的过程。它意味着通过更改程序来改进程序结构性，降低程序复杂性，让程序变得更加易于理解。25软件重构和软件再工程区别尽管再工程和重构都是要将软件变得更加容易理解和修改,但它们并不是同一回事。再工程发生在系统已经维护了一段时间并且维护费用不断上升的情况下。通过使用自动化工具来处理并再工程一个遗留的系统，产生一个更具可维护性的新系统。重构是一个连续不断的改进过程，它贯穿于开发和进化的整个过程。重构是要避免导致成本上升和维护困难的结构以及代码的退化问题。26重构需要被改进的情况（Fowler）冗余代码长方法选择语

10、句数据聚集假设的一般性。279.4 遗留系统管理遗留系统（legacy system）是“一个已经运行了很长时间的，对我们的机构来说是很重要的，但是又不能适应当前问题的的软件系统”。由于遗留系统所完成的是关键业务，所以不能简单丢弃。28遗留系统的决策1.彻底抛弃这个系统 对业务过程处理无有效价值2.继续维护这个系统系统统有存在的必要，系统运行相当平稳，而且用户没有提出太多对系统变更的要求时3.对系统再工程以改善其可维护性当系统质量由于经常性的变更已经下降，而且仍然需要做经常性的变更时，应该选择这个方案4.以一个新的系统代替整个或部分系统开发新系统的开发成本非常合理时29软件质量与商业价值30业务价值评估评估业务价值应考虑的视点系统最终用户客户生产线管理者IT 管理者资深管理者方法访问来自不同视点的代表，收集其看法形成业务价值的总体概况，全面评估业务价值，并从