《软件工程》第9章软件演化（未完待续）

    大型软件系统通常有一个很长的生命周期。企业软件的成本很高，所以一个公司会使用一个软件系统很多年来收回前期对软件产品的投资。因此，那些很多年以前就取得成功的软件和产品，依然会定期发布新版本。

    在系统开发完成后，如果要使其继续有用，对它进行修改是不可避免的。由于业务变更和用户期待的改变，使得对已有系统的新需求浮现出来。由于各种原因，软件的某些部分需要修改，例如，修复运行中发现的错误、适应新的运行平台、提升性能或其他的非功能性特性。所有这些意味着在系统交付后，软件系统总是在不断演化以满足变更的需求。

    企业必须不断改进他们的软件以确保他们能够持续从中获得价值。他们的系统已经成为组织的重要经营资产，必须投资进行系统变更以保持其价值。通常，大多数大型公司在维护系统上的开支要比系统开发上的开支多很多。

    对于一些大规模的企业系统来说，软件演化的代价极其昂贵，因为一个相对独立的系统往往是“由系统构建的（整体）系统”中的一部分。在这种情况下，进行变更需要考虑的不仅仅是系统本身的影响，还有对全局的（整体）系统中其他部分的影响。因此，对某个系统进行变更通常意味着还需要对其他系统也进行相应的修改，以适应环境的变更。

    因此，在确认和分析变更对系统本身产生影响的同时，还需要评估它会对运行环境中的其他系统产生怎样的影响。

    已安装的系统，随着业务和它的环境的改变，其需求也随之改变。因此，系统通常会定期发布新版本以实现改变和更新。因此，软件工程是一个贯穿系统生命周期的，由需求、设计、实现、测试组成的螺旋过程（见下图）：开始于系统的第1个发布版本的创建；一旦交付使用，变更提出，则第2个发布版本的开发立刻开始。事实上，甚至于在系统部署之前，演化的需求可能已经变得很明显，以至于在目前的版本发布之前，软件的后继版本就已在开发中了。

    最近10年，软件螺旋式迭代的周期正变得越来越短。在互联网普及之前，软件新版本发布的周期大约是2~3年。而如今面对激烈的竞争和及时的用户反馈，很多软件与Web应用的更新周期甚至可以短至数周。

    这个软件演化模型是针对一个专门组织既负责最初的软件开发又负责以后的软件演化这种情况的。当软件开发完成后，团队需要将工作无缝衔接到软件演化上，并且开发过程中使用的过程和方法会始终贯穿于软件的整个生命周期当中。大部分打包的软件产品是按这种方式开发的。

    对于定制化软件，通常使用另一种不同的方法。一个软件公司为客户开发软件，然后由客户自己的开发团队接管这个系统，即由他们负责软件演化。还有另一种选择是，软件用户和另外一家公司签订一个单独的合同，要求其负责系统的支持和演化。

    在这种情况下，螺旋进程经常是不连续的。需求和设计文档不能从一个公司传递到另一个公司。公司可能通过合并或重组继承来自其他公司的软件，于是发现需求和设计文档都必须进行变更。当从开发到演化的转换不是无缝衔接时，软件移交之后的变更过程被称为“软件维护”。

    另外有一种软件演化生命周期的另一种视图，如下图所示。在这个模型中，他们把演化和维修区别开来。演化阶段涉及软件体系结构和功能性的重大改变；而维修阶段所做的都是一些相对较小但必不可少的修改。

    当软件初步被成功使用时，许多关于需求变化的提议会被采纳和实现。这是演化阶段。但是，随着软件被更改，它的结构也在退化，更改的成本也变得越来越大。这种情况通常发生在使用数年之后，其间也有其他环境的改变，例如硬件或者操作系统。在生命周期的某些阶段软件会到达一个转折点，在此之后软件进行重大的改变以及实现新需求都会变得越来越不划算。这时，软件从演化阶段转为维修阶段。

    在维修阶段，软件仍然是可用的并且一直在使用着，只有一些小的局部的调整需要做。在这个阶段，公司经常会考虑怎样将软件更换掉。在最后阶段，软件仍然在使用，但是只有少量必需的变更会被执行，因而用户需要想办法去绕过发现的某些问题。最终，软件退役并完全退出使用。这通常会包含将旧系统的数据迁移到新的替代系统上，其中会包含一些额外的成本。