1 Hybrid Re-engineering
随着软件工程理论的不断完善，各种新的再工程模型被提了出来。下面将介绍一种再工程模型：Hybrid Re-engineering。
1.1 软件再工程的一般模型
再工程是从已经有系统的源代码开始的，根据测试结果以及目标系统的实现做出决定。下图说明了软件再工程的一般模型，描述了针对软件开发过程中各个阶段的再工程过程。
再工程是实现开始，通过逆向工程将软件概念不断抽象，并重新思考，重新评估整个工程以及现有代码。然后运用正向工程，使用瀑布模型开发目标系统。在行业报告中提到，在再工程过程中，有大约60%的时间花费在逆向工程上。在完成目标系统的同时，许多项目还要展现出它们的必要功能都被很好的保留了，而且性能还有所提高。
和所有的项目一样，再工程项目在资源和时间都有限制。因此，需要在保持系统功能以及提高系统性能的同时，使再工程的花销最小化。包括NASA在内的很多组织都在研究通过使用可复用的软件包来降低开发时间、开发成本以及风险。现在市场上有很多软件包产品出售（COTS, Commercial Off The Shelf），下文中会使用COTS这个名词来代表这一类软件。
在试图降低再工程的开销的过程中，管理者根据一般的经验发现一个软件中的20%的部分可能导致了80%的bug，同时大约软件15%的部分就包括了整个软件85%的功能。所以他们就对是否需要对整个系统进行再工程提出疑问。是否可以只对系统中那些导致绝大部分bug的代码或是包括了系统绝大部分功能的代码进行再工程呢？这样的思考过程引入了一种新的再工程形式。
1.2 Hybrid Re-engineering
SATC(Software Assurance Technology Center)正在为NASA的再工程项目做些工作，在改进软件性能的同时，辨识软件开发过程中的风险，并使其最小化。在这些项目中，根据整个项目的需要，项目的预算以及时间表这几个因素来对软件过程中的一些阶段进行了合并。SATC将这种对软件过程阶段的合并以及这种从已有系统到目标系统的改造方法称为“Hybrid Re-engineering”。
下图描述了一个已经使用一段时间的“传统”软件系统。在这个再工程例子中，我们假设项目是从Fortran语言移植到C++(但不一定是使用面向对象设计思想)
在看了现有软件系统和代码之后，管理者总结出了两类代码：1. 相对“稳定”的代码，它们基本上没有被修改过而且它们的需求没改变。2. 还有一些代码是被修改了多次的，它们变得不稳定，不可靠而且很难维护。对那些“稳定”的代码进行再工程可能就不需要进行逆向工程的所有步骤，也不需要重新考虑需求。可能只需要简单的使用新的编程语言在新的环境下对这部分代码重写就可以了。
就像上面提到的，逆向工程的花销占用整个再工程项目花销的60%。如果这一步中的某些部分可以被省略，就可以节省一些时间并能减少开销。下图描述了这种新的再工程模型，它是对一般的再工程模型的改造。
Hybrid re-engineering和传统再工程方法类似，但它要考虑一些额外的因素。当再工程项目开始时，要对再工程的开销和质量，以及投资的期望回报进行初步说明。然后应该对现有系统进行分析，来决定hybrid re-engineering的可行性。对现有系统的分析可以对优化策略的决定提供指导,并可以估算出目标系统的开销。一旦决定使用hybrid re-engineering，就需要对系统进行另一次分析。
Hybrid re-engineering方法的第一步是研究软件系统以及再工程项目的需求和约束。项目约束要包括逆向工程和正向工程可用的时间，其中要考虑研究可用的COTS的时间（包括COTS是否容易上手）。如果使用了COTS，那么正向工程的开发时间应该缩短，同时需要额外的时间来测试软件的整合情况以及目标系统和COTS之间的接口。预算上的约束也要考虑在内：要买到实现必需功能的COTS和买到提供希望得到的功能的COTS各要花多少钱。做出一些取舍是必要的，这时就需要对需求划分优先级。
第二步就是要对现有系统进行一次深层次的分析，集中针对功能以及适应移植或是使用COTS的代码段。在传统的再工程过程中，对现有系统的分析是用来对系统以及维护成本进行评估。在再工程过程完成之后，这些信息被用来评价开销和系统的改进程度。Hybrid re-engineering在考虑这些因素的同时，还要研究现有系统的一些其它特性。在对现有系统做出评估的过程中，要对实现相关功能的代码段进行标识。还要对这些标识出的代码段进行进一步的评估，来决定哪些功能是需要的、哪些功能是不再需要的以及哪些是用户已经习惯使用的等等。然后根据维护成本和现有结构的质量对这些代码段进行排序。在评估过程中还要标识出那些项目特有的，不能被COTS代替的功能点。这些信息将被用来决定是直接进行移植，还是使用COTS替代，或是重写代码。
一旦软件系统的功能点被分离出来了，那么移植、使用COTS替代和重写代码就可以三线并进了。这三部分的时间表可能根据其复杂程度的不同而不同。
任何的再工程项目都有可能在进度、功能实现、开销和质量这几方面中遇到风险。Hybrid re-engineering就是为了在一定程度上降低一些风险而被引入的。因为我们可以认为COTS有很高的可靠性并且需要很少的开发时间，同时代码的移植会比重写代码开销更少。
因为hybrid re-engineering整合了移植、使用COTS和重写代码这三部分，所以可能会有一些由这三部分引入的新的风险出现。比如hybrid re-engineering是多个软件系统的集成，那么一个新风险就是各个系统之间的接口是否可以正常工作。另一个可能的新的风险就是COTS是否可会像预期的那样发挥功能。
下面将详细说明一下移植、使用COTS以及重写代码这三条线的过程。
1.2.1 使用COTS
在使用COTS时，必须认定软件需求和功能都适合使用COTS实现。下图描述了在再工程过程中使用COTS。
在通过逆向工程抽象出需求之后，很重要的一件事就是把那些必须被目标系统包括的功能从那些用户因为用着顺手或是已经形成使用的习惯而认为应该在新系统中包括的功能中分离出来。这个分离需求的过程对于COTS的选择十分重要。在这之后的重要步骤是分析出COTS可以提供的功能占软件需求的百分比，以及都是哪些功能。这个信息将被用来计算在使用COTS之后还需要多少工作量才能完全满足软件的需求。COTS的易用性也要被评估，来决定需要多少额外时间进行培训。当然COTS的稳定性也要考虑。在考虑过所有这些因素之后，应该估算一下如果从现有基础上自行开发（包括测试花费的时间）所产生的开销，并将其与使用COTS的开销进行比较。
使用COTS的好处就是减少了开发时间和开销。因为COTS产品通常都是经过商业级测试的，有很高的可靠性，而且培训措施和文档都很不错。还有一个额外的开销被节省了，因为COTS是由开发商维护的。
尽管使用COTS软件减少了开发时间并且增强了可靠性，但它也引入了一些额外的新风险。一个主要的风险就是COTS可能并不能像期望的或是广告上说的那样工作，也可能COTS本身并不可靠,还是不成熟或是未完成的。这样的软件包通常还处于持续开发阶段，需要进行经常升级。最坏的情况是COTS做出的改变修改或是去掉了某些在目标系统中需要的功能。这样的COTS就需要做出修改来满足需求，但这样就会增加开发时间并降低了可靠性。另外，使用COTS可能会限制软件系统的可增强性。因为出于法律或合同原因，是不可以对COTS提供的功能做出修改的。对于COTS的不熟悉同样会导致额外的培训时间。
1.2.2 移植
在hybrid re-engineering的移植过程中会应用一些工具自动地将现有系统的代码转换成目标系统的代码语言中。在这一过程中，现有系统中那些相对“稳定”，没有经过什么设计和架构修改的代码必须被标识出来。这可以通过对代码进行分析或是借助更改报告来完成。这些代码的质量会被评估，来看看它们是否是可以保留的。下图描述了这一过程。
使用移植的好处在于减少了时间和开销，因为只有最小化的逆向工程需要进行（如果真有需要的话）。同时维护人员仍然可以明白程序的流程，因为它们并没有改变。测试过程中也可以节省不少开销，因为很多测试用例都是可以复用的。
这种移植可能会带来两种风险。第一个风险是源代码翻译器本身并不足够聪明，因为它进行一行一行的翻译并不能充分利用目标语言的特性。一般来说，源代码翻译器只能成功翻译90-95%的程序，而且翻译后的代码可能并不能产生正确的输出，因为还有一部分没有被正确翻译而导致的功能缺失。第二个风险是在选择哪些代码被用来进行翻译时。不好的设计或是低质量的代码会导致目标系统的质量下降。
1.2.3 重写代码
下图描述了这个过程，它和传统的再工程过程很相似。
在这一过程中，首先要进行逆向工程。那些COTS无法实现的功能或是不能通过移植实现的功能都要被标识出来，然后要分离出这些功能的需求和设计。接着进行正向工程。从需求分析开始，要分析出哪些功能是不需要的。其它的过程就和别的开发过程类似了，重新设计，如果需要的话使用面向对象结构，编写代码，最后是测试。
重写代码的优点是编写出的代码将会完全满足需求。设计必须满足新的结构需求，比如使用面向对象技术。新开发出的代码会是高质量的，结构清晰，只需要少量的维护工作。而且新语言的特性可以得到充分应用。
像其它软件开发一样，重写代码同样可能会有进度、质量和可靠性上的风险。因为所有原有软件系统特有的功能点都通过重写代码实现的，那么一个风险就是如果有一个特有的功能点没有被标识出来的话，新系统的功能就是不完整的。另一个风险是重新编写的代码质量可能会比较差，这将导致在维护上的很大的开销。和任何开发过程一样，进度和预算也是主要风险之一。
1.3 Hybrid re-engineering的收尾工作
一旦系统完成，剩余的两个工作就是测试和检验。首先，全面的系统测试和集成测试是必须，用来保证所有原有系统的功能都已经被移到新的系统中了，同时各个组件之间可以像一个整体一样正常工作。第二，检验是必须的，我们是知道所有的投入和我们得到的是否相符。
1.4 Hybrid re-engineering的优点
Hybrid re-engineering的优点是从再工程的应用以及Hybrid方法中继承下来的。一般来说，再工程与构建一个新的软件系统是相反的。因为现有软件系统中存在着看不见的业务应用过程和业务逻辑。这些可能被深深地嵌套在业务流程之中，简单到一个数据结构，复杂到一个数学算法，而这些信息的唯一来源就是现有系统的源代码。因此，再工程的一个优点就是易于捕获这些过程，并将它们转移到新系统中。另一个好处就是在再工程过程中，现有系统被重新实现，在保持了原有功能的同时使用了很好的软件开发方法，新的语言特性等。可靠性和可维护性也会大幅提高。
Hybrid re-engineering在减少开发时间和开销上还有一些额外的好处。首先，因为最小化的逆向工程的使用使得开发时间缩短。其次，COTS的使用减少了正向工程的开发和测试时间，从而减少了开销。选择适当的COTS同样可以增强系统的可靠性。
1.5 Hybrid re-engineering的风险
所有的软件开发都可能在进度和开销上遇到风险。做为一种软件开发方法，hybrid re-engineering同样难以避免这样的问题。因为它组合应用了三个开发方式，所以它可能会有所有三个方式的风险。做为一种再工程方法，hybrid re-engineering同样可能有功能和质量方面的风险（现有系统的功能必须在新系统得到保留，同时软件系统的质量要有所改进，这意味着操作和维护开销的降低）。虽然hybrid re-engineering有这样那样的风险，但是鉴于它所带来的好处，它还是一个好的再工程方法。
