信息系统存在很多共性，如果作为产品来开发，那么如何能够通过平台来进行重用和扩展，业界中的产品线工程方法就是进行大范围复用的一种方法。 在园子里也住了不短时间，发现关注技术的占多数，而除了技术外，软件工程中还有很多我们需要关注的，如下图，软件架构平台基于产品线工程开发。前一阵子对Scrum进行了介绍，接下来准备写几篇产品线相关的内容，本篇将对产品线中的四个主要概念进行简要的说明（可变性管理、商业驱动、架构驱动、两阶段生命周期） ，希望对不熟悉产品线知识的有所帮助。

在讲解之前先解释两个概念：

• 产品族：一组使用通用的资源来构建的产品。一个产品族是基于它的成员产品的结构相似性而定义的。产品族成员建立在一个通用平台之上，主要基于产品之间的技术通性而设置的。产品族可以重用于多个产品线。
  
• 产品线：一 组共享一组公共管理的特征的产品，这些特征满足一个选定市场的特定需要。一个产品线的定义是基于市场策略的，而不是基于它的成员产品之间的技术相似性。为 一个产品定义的特征，可能需要完全不同于其它成员产品的解决方案。一个产品线可能是与一个产品族一起提供出来，但是它也可能需要不止一个产品族。

在下面介绍过程中，在谈架构平台时更偏向于产品族的概念。

为什么需要产品线方法

随着软件应用的普及，企业对软件也越来越重视，不断的要求采用软件提高效率，提升技能增强企业竞争力。随着客户的增多，软件企业这时需要 面对更多的客户，处理共性和个性问题。如何保证低成本、高质量、快速上市等要求就成为了企业竞争力的主要表现之一，而产品线工程方法就是支持这种大范围重 用（large-scale reuse）的方法。产品线区别于传统的代码重用就是大量的使用重用（可以达到90％），不仅仅是代码，还包括需求、业务等。在《OpenExpressApp架构－一个信息系统的平台》中我画了一个重用的图，产品线将基于更大范围的重用进行开发。

 

• 减少成本

大家都知道，软件的开发成本仅是总体成本的一部分，软件的维护成本是更大的一块，产品线工程除了可以减少开发成本外，维护成本也可以大大降低，不再需要维护大量不同版本不同架构的代码，也没有大量不同的文档需要维护。

• 快速上市

产品基于重用开发，不需要在每个开发环节都重头开始，这样可以大大的缩短上市时间。

• 减少风险

由于产品线除了可以重用框架，对同类型产品也可以重用开发方法，这样对于任务估计、开发计划都可以很好的重用，这样也可以减少项目开发的风险。

• 提高质量

软件基于大量成熟和经过验证的核心资产进行开发，这些组件都已经经过大量使用并得到验证，所以在项目中应用可以保证出现的问题很少。

虽然产品线预计带来的效果很迷人，但是它并不是一开始就可以给企业带来效益的，它必须进行一些前期的投资（核心资产的开发、组织的转变等）才能获得回报，右图是产品线的经济走线图，在第三个项目时才能达到收支平衡。

产品线方法基本原则

• 产品线方法与传统的单项目开发的主要不同在于关注点的转移：从单独的产品到产品线的项目。这个转移暗示了一个策略：从特定的项目开发到特定业务领域产品的愿景。
• 产品线工程对开发以重用（development for reuse）和使用重用来开发（ development with reuse）有 明确的区分。对比传统的重用，产品线基础设施包括产品开发周期的所有资产（框架、业务模块、开发计划，需求到测试阶段），而不只是在代码级的重用。这些重 用资产都包含明确可变性说明的，如需求原型中表明这个功能只在特定子产品中才包括，这对产品业务的理解要求就更高了。

• 四个主要原则
  • 可变性管理（Variability management）：每个产品都是核心资产的变体，必须系统化的管理产品的可变性，这对业务分析的要求就更高了，由于它在产品开发生命周期的重要性，下面会单独进行说明。
  • 商业驱动（Business-centric）：产品线瞄准的是长期的商业战略，而不是仅仅走单。 传统的软件开发基于各个单独的项目进行，产品线开发要求系统全面的对市场进行定位。商业驱动方法需要决定哪些功能应该包括在产品线中，是在领域工程还是应 用工程中进行。这个在产品线中叫做确定范围（scoping）。在《软件产品线实践和模式》中提出一个公司是采用一条产品线还是多条产品线？书中提到大型 产品线只有同时具备以下两个条件时才会起到好的作用：第一， 产品具有足够多的相同点，将它们作为一条产品线是有利可图的，第二，公司有能力控制这样大大型的市场运作、开发以及其他方面。如果暂时不能满足这两个条 件，那么还是分为两个产品线进行，而不能一味的一个公司只要一个产品线。
  • 架构驱动（Architecture-centric）：技术上需要支持最大化的重。产品线工程依赖一个通用的参考架构（reference architecture），特定项目架构都基于参考架构进行开发。
  • 两阶段生命周期（Two-life-cycle approach）：每个产品基于平台开发，产品和平台有各自的开发团队和开发生命周期。如果条件不允许需要同时做这两种工作时，自己一定要清晰自己所做的工作哪些是领域工程，哪些是应用工程。下图为两阶段图：框架分为两个阶段：领域工程和应用工程。 领域工程产出平台的公共核心资产，应用工程产出产品。在整个开发生命周期中，存在9个子流程，八个流程互相匹配成四组类似流程，需求、设计、在实现和测试 领域工程和应用工程都存在，每一匹配组的流程都紧密相连。领域工程的子流程目的在于满足通用需求，而在应用工程是为了生产可供使用的产品。应用工程的子流 程可以重用多达90％的领域工程资产，在生产过程中会不断的提供反馈给领域工程，这种循环反馈才能确保平台一直都能有效的生产出最终产品。

可变性管理（Variability management）

产 品线工程是支持一系列有共性的产品，下图比较清楚的表明了产品的主要点，可变性（variability）是很重要的一个概念，在产品开发过程中可变性必 须明确的定义、表达、开发、实现和不断的完善，它必须是被管理的。可变性管理应该在早期范围界定是就开始，它与所有核心资产相关。其实现在很多公司，只要 做的软件是产品性质的，很多都是服务大量不同客户，都需要进行可变性管理，但是因为没有明确提出是在进行产品线开发，所以可变性的概念并没有提出来，所以 自然也得不到重视和研究。可变性管理应该成为产品开发的核心问题之一，这也是我后年的关注点。

可变性类型

上图中显示了可变性的三种主要类型：共性、变化点、基于特定产品。要注意，随着产品的进展，基于特定产品的功能可以会变成变化点，变化点可能会变成共性。

共性和变化点在领域工程中解决，特定产品功能在应用工程解决。

三种基本的实现可变性技术

 

可视化可变性

上面简单讲了一下可变性的概念，那么我们如何表达出来并与别人交流呢？业界有通过模型来表达的，

下图展现了一个可变性模型和领域模型的关联。