软件演化总结
软件演化
为什么系统要演化：大型软件系统通常有一个很长的生命周期。在系统开发完成后，如果要使其继续有用，对它进行修改是不可避 免的。由于业务变更和用户期待的改变，使得对已有系统的新需求 浮现出来。由于各种原因，软件的某些部分需要修改，例如，修复运行中发现的错误、适应新的运行平台、提升性能或其他的非功能性特性。所有这些意味着在系统交付后，软件系统总是在不断演化以满足变更的需求。
为什么系统演化贵？【谁贵？】通常，大多数大型公司在维护系统上的开支要比系统开发上的开支多很多。【所处的环境？】对于一些大规模的企业系统来说，软件演化的代价极其昂贵，因为一个相对独立的系统往往是“由系统构建的（整体）系统”中的一部分。【棕地软件开发】因此，在确认和分析变更对系统本身产生影响的同时，还需要评估它会对运行环境中的其他系统产生怎样的影响。
开发和演化的螺旋模型：周期：2~3年=>数周。同一个团队：这个软件演化模型是针对一个专门组织既负责最初的软 件开发又负责以后的软件演化这种情况的。不同一个团队：一个软件公司开发，客户自己的开发团队接管或者另外一家公司接手，软件移交之后的变更过程叫“软件维护”。定制化软件通常是这种方法。
演化和维修：软件软化生命周期的另外一种视图。演化阶段涉及软件体系结构和功能性的重大改变。维修阶段所做的都是一些相对较小但必不可少的修改。
演化过程：
变更识别和演化过程：软件变更与软件演化并不存在绝对的标准。在所有的组织中，正式或非正式的系统变更建议都是系统演化的动力。
软件演化过模型的通用模型：在发布规划期间，考虑所有提出的变更建议（故障修复、平台适应和系统改进），然后决定在系统的下一个版本中实现哪些变更。
实现变更：如果需求规格说明和设计文档是存在的，那么在实现变更后，应 该对其进行修改以反映系统的变化情况（见下图）
紧急变更的情况：导致出现紧急的变更原因：1、一个严重的系统缺陷被发现，必须修复该缺陷以使常规的系统运行可以继续或者解 决一个严重的信息安全漏洞。2、如果系统操作环境的 变更中有不期望的情况发生，那么就会破坏正常的操作3、如果系统上运行的业务有未预料到的改变发生，例如，有新的竞争对手出现或者有新的法律生效并影响到了系统。
紧急修复过程：不是按正常的过程去修改需求和设计，而是要对程序进行紧急的修补来解决突发问题。
1、紧急修复存在的问题：尽管你打算记录需求和设计方面的变更，却可能又有一个急需的修补在等你完成。它的优先权高于文档记录。最后，最初的变更被遗忘了，系统文档与代码再也 不能一致了。加速了软件的老化过程，并使未来的变更计划更困难，维护费用上升。解决办法：重构
2、敏捷方法和过程会在程序演化和程序开发中用到紧急修复过程。
实际上，因为这些方法是基于增量开发的，敏捷开发向交付后演化的转变应当是无缝衔接的。（同一个团队时）
然而，当一个开发团队向另外一个负责演化的团队交接时，有以下两种问题可能出现：（不是同一个团队时）：1、开发团队运用了敏捷方法，但是演化团队却不熟悉敏捷方法而选 择了一个计划驱动的方法。演化团队期望详细的文档可能没有。2、计划驱动的方法被用于开发过程，而演化团队选择使用敏捷方法。演化团队可能不得不从头开发自动化的测试，而且不会有像敏捷开发过程中所期待的系统代码重构和简化。
遗留系统：不仅仅是软件系统，还是更广阔的社会技术系统，其中包括硬件、软件、各种库，以及其他支持性的软件和业务过程。另一种看待这些遗留系统组成成分的方式是分一系列的层，右图所示：
系统硬件。遗留系统当初开发的时候可能是针对一些老的硬件编写的。
支持软件。遗留系统可能依赖于一系列支持软件，从操作系统以及硬件厂商提供的一些工具到用于系统 开发的编译器。这些软件也可能过时了。
应用软件。这些应用程序是在不同的时间开发的。
应用数据。这些数据可能会不一致，可能会在多个文件中重复出现，还可能分散在一些不同的数据库中。
业务过程。业务过程可能会围绕一个遗留系统设计并且受该系统提供的功能的制约。
业务政策和规则。这些政策和规则包括关于业务应当如何开展的定义以及对于业务的约束。遗留应用系 统的使用可能会蕴含在这些政策和规则中。
遗留系统可能存在的问题有哪些？
技能的缺乏：一些遗留系统使用的是已经不再广泛应用的古老编程语言开发的；
信息安全漏洞：因为这些系统是在互联网广泛使用之前开发的；
与用现代变程序员编写的系统进行接口交互时所面临问题；
系统硬件过时并且越来越贵：最初的软件工具商可能已经退出相关业务，或者不再维护当初用于开发系统的支持工具。
遗留系统：发现问题、分析问题、解决问题（1替换老系统、2修改老系统）
1、替换老系统：企业使用更加现代化的同类系统替换这些遗留系统有太贵并且风险太大的弊端。原因有以下四点：1.遗留系统很少有一个完备的规格说明。2.业务过程以及遗留系统的运行方式经常不可避免地交织在一起。3.重要的业务规则可能会蕴含在软件中，并且可能并没有进行专门的文档描述。4.新的软件开发从内在来讲也是充满风险的。
1、修改老系统：对使用多年的遗留软件系统的修改尤其困难，主要原因：1、程序风格和使用习惯不一致2、用过时的编程语言实现的3、系统文档化不充分而且过时4、系统结构退化，系统难理解5、使用特定的机器和语言进行优化难以理解6、数据存在多个结构不匹配的文件里
遗留系统管理：先对遗留系统进行现实的评估，然后做出适当的决策，有以下4种基本选择：
1、彻底废弃2、常规维护3、再工程4、系统代替
在评估一个遗留系统的时候，必须同时从业务（如回报率）和技术（如维护费用）两个视角来看待它。一、从业务的视角看，必须对该系统的业务价值做出评估。二、从技术的视角看，必须对应用软件、系统支持软件和硬件质量做出评估。
为了评估一个系统的业务价值，我们必须假设是系统的所有者，比如最终用户和他们的经理，对系统提出以下4个方面的问题。
系统的使用。如果系统只是偶尔被使用或被很少一部分人使用，那么它们含有较低的业务价值。然而，一定要注意不经常使用但却重要的系统。
支持的业务流程。当引入一个系统时，我们就要设计业务流程来开发系统的能力。如果遗留系统难以改变，由于不能引入新的流程，很可能使一个系统的业务价值降低。
系统的可靠性。系统可靠性不仅仅是一个技术问题，也是一个业务问题。如果系统不可靠，那么系统的业务价值较低。
系统的输出。如果业务依赖于这些输出，那么系统就含有高的业务价值。相反，如果这些输出可以用某种方法很容易地产生，或者系统产生的输出很少被使用，那么它的业务价值就很低。
若从技术的角度来评估软件系统，需要考虑应用系统自身和系统的运行环境。
环境评估的因素（技术角度）：
供应商稳定性：供应商还存在吗？供应商财务上是否稳定？供应商是否会继续存在？如果供应商不再从事相关业务，是否有其他人可以维护该系统
失效率：所报告的硬件失效率是否很高？支持软件是否崩溃并迫使系统重启
年限：硬件和软件已使用多少年？硬件和软件越老就越落后。它们可能仍然正确运行，
但转向一个更现代的系统会带来显著的经济和业务上的回报
性能：系统的性能是否足够？性能问题对系统用户是否有显著的影响
支持需求：硬件和软件需要什么样的本地支持？如果这些支持成本很高，那么可能值的考虑下系统替换
维护成本：硬件维护和支持软件许可证的成本是什么？比较老的硬件的维护成本可能会比现代的系统更高。支持软件可能会有较高的年度许可成本
互操作性：该系统与其他系统的接口交互是否存在问题？例如，编译器是否可以与当前的操作系统版本一起使用
应用评估的因素（技术角度）：
可理解性：理解当前系统的源代码有多难？所使用的控制结构有多复杂？变量的名字是否能 反映它们的功能？
文档：可用的系统文档有哪些？文档是否齐全、一致并进行了及时更新？
数据：系统是否存在一个显式的数据模型？文件之间的数据在多大程度上存在重复？系统所使用的数据是否及时更新而且一致？
性能：应用的性能是否足够？性能问题对系统用户是否有显著的影响？
编程语言：开发该系统所使用的编程语言是否存在现代的编译器？该编程语言是否仍然被用于新系统开发？
配置管理：系统的所有部分的版本是否都由一个配置管理系统进行管理？当前系统中所使用的构件的版本是否存在一个明确的描述？
测试数据：系统的测试数据是否存在？当新特性被增加到系统中时，所执行的回归测试是否有记录？
人员技能：具有维护该应用的技能的人是否存在？对于该系统有经验的人是否存在？
要收集量化的系统数据来帮助我们对系统质量做出判断。质量评估中可能用到的数据有：
请求系统变更的数量。系统变更容易造成系统结构的损坏，并为进一步变更增加了难度。这个数值越高，系统的质量也越低。
用户界面数量。这对于基于表格的系统来说是一个重要的因素。在这种系统中，每一张表格都可以看作一个独立的用户界面。界面的数量越多，越容易发生界面的不一致和冗余。
系统使用的数据量。使用的数据量（文件的数量、数据库的规模等）越大，就越有可能出现降低系统质量的数据不一致性。当数据经过长时间的积累，不可避免地会存在错误和不一致。清洗旧数据是一个非常昂贵和耗时的过程。
如何解决遗留系统多、很重要，但是资金少？理论上，应该根据客观的评估结果做出处理遗留系统的决定。实际上，做出的决定并不是可观的，而是基于组织或政治上的考虑。
软件维护
当软件交付后，软件维护就成为软件变更的一个常规过程。
变更的实现时修改已有的系统构件以及在必要的地方添加新构件到系统中。
有3种不同类型的软件维护（三者没有明确的界限）：1、缺陷修复。通常改正代码错误费用相对较低，改正设计错误费用就高得多，因为要重写很多程序构件。2、平台适应。环境上的改变包括硬件变化、操作系统平台的变化或其他的支持软件的变化。3、系统改进。当系统需求随着组织因素或业务改变而变更的时候，增加或修改系统功能。
软件维护费用大致分布：修复系统缺陷不是最昂贵的维护活动。通过系统演化适应新环境以及新的或发生变化的需求通常会花费大部分的维护工作量。（功能的增加修改最多。）
通常在系统投入使用之后增加功能，较之在开发期间实现相同的功能代价要高得多，主要原因如下有以下4点：投入增加的原因：
1.团队稳定性。负责系统维护的新团队或个人既不了解该系统，也不了解系统设计决策的背景。
2.糟糕的开发实践。系统的维护合同一般是独立于系统开发合同的。开发团队缺乏动力去写维护性好的软件。
3.人员的技术水平。维护人员一般都缺乏经验，而且不熟悉应用领域。此外，旧的系统可能是用已经淘汰的程序 语言写成的必须经过学习方能胜任维护工作。
4.程序年限和结构。随着程序不断的变更，其结构受到了破坏。结果是，随着程序年龄的增加，它们变得越来越不容易理解和变更。
投入力量设计和实现一个系统来降低未来变更的成本几乎总是合算的，但是实际上，大多数企业都不太愿意在软件开发上花费更多的精力来降低长期维护成本，不情愿的两个原因：
1.公司制定季度或年度支出计划，并鼓 励管理人员减少短期成本。投资可维护性会导致短期成本上涨，这部分是可衡量的。然而，与此同时，长期收益却很难衡量，所以企业不愿意将钱花在未来回报未知的事情上。
2.开发人员通常不负责维护他们所开发的系统。因此，他们很少想到通过一些额外的工作来降低维护成本，因为他们不会从中获益。
解决这个问题的唯一方法：集成开发和维护，从而使最初的开发团队在整个软件生命周期中始终对软件负责。
维护预测：关注评估软件系统可能需要的变更，针对最有可能发生变更的软件构件进行特别的设计，从而使其具有更好的适应性。（预测系统变更、预测可维护性、预测维护成本）
预测变更请求的数量：当系统已经投入服务的时候，可以使用过程数据来帮助预测可维护性。 对可维护性评估有用的过程度量包括以下4个：
1.请求纠正性维护的数量。如果失败报告的数量在增加，这可能暗示着在维护过程期间有更多的错误引入程序之中了，这样可能会导致系统可维护性的下降。
2.影响分析所需的平均时间。它反映了受到变更请求影响的程序 构件数量。如果这个时间在增加，就暗示着越来越多的构件受到影响，可维护性正在下降。
3.实现一个变更请求的平均时间。如果实现变更的时间在增加，这可能预示着可维护性在下降。
4.突出的变更请求的数量。如果这种变更请求数量随着时间在增加，可能意味着可维护性在下降。
软件再工程：遗留的老系统，它们是很难理解和进行变更的。
为了使得遗留系统的维护问题变得更简单，可以再工程这些系统以增强它们的结构性和可理解性。
再工程包括对系统重新建立文档、重构体系结构、用一种更先进的程序设计语言转换系统、修改和更新系统的数据结构和系统的数据取值。
一般来讲，软件的功能不会改变，也应当避免对系统体系结构的大的改动。
软件再工程优势：再工程相对于直接替换系统来说，有两个重要的优势：
1.较小的风险。对某个关键业务软件的重新开发是要冒很高风险的。系统描述中会发生错误，而且开发过程中也会出现种种问题。在引入新软件上时间的拖延将意味着商业上的损失招致额外的花费。
2.较低的成本。较之重新开发一个软件所用的成本，再工程的成本要小得多。即使运用先进的软件技术，重新实现的花费可能还是要比再工程的花费多。
软件再工程过程的通用模型:过程的输入是一个遗留程序，输出是同一个程序的一个已改进
和重新构造的版本。
软件再工程的缺点:系统经过再工程后能改善的范围受到一定的限制。（改善有限）举例来说，1、它不可能把面向过程的系统转换成面向对象的系统；2、主要体系结构的变更或对系统数据管理的重新组织不能自动地执行， 因此需要额外的高成本；3、虽然再工程能改善可维护性，但经过再工程的系统不可能像用现代软 件工程方法开发的新系统一样好维护。
软件重构：重构（refactoring）是提升程序以减缓其由于更改而退化的过程。当重构一个程序时，不应该增加其功能，而应该注重程序的改进。可以把重构看成是“预防性维护”，以此来减少未来变更产生的问题。
软件重构与再工程的区别：再工程发生在系统已经维护了一段时间并且维护费用不断上升的情况下，通过使用自动化工具来处理并再工程一个遗留系统，产生一个更具可维护性的新系统。重构是一个连续不断的改进过程，它贯穿于开发和演化的整个过程。重构是要避免导致成本上升和维护困难的结构以及代码的退化问题。
存在一些固定模式的情况，其中程序的代码能够通过重构被改进的情况包括如下：需要重构的情况：1、冗余代码2、假设的一般性3、长方法4、数据聚集5、选择语句