软件产品线工程方法－四个主要方法原则

本文已挪至 http://www.zhoujingen.cn/blog/1431.html

信息系统存在很多共性，如果作为产品来开发，那么如何能够通过平台来进行重用和扩展，业界中的产品线工程方法就是进行大范围复用的一种方法。在园子里也住了不短时间，发现关注技术的占多数，而除了技术外，软件工程中还有很多我们需要关注的，如下图，软件架构平台基于产品线工程开发。前一阵子对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）是很重要的一个概念，在产品开发过程中可变性必须明确的定义、表达、开发、实现和不断的完善，它必须是被管理的。可变性管理应该在早期范围界定是就开始，它与所有核心资产相关。其实现在很多公司，只要做的软件是产品性质的，很多都是服务大量不同客户，都需要进行可变性管理，但是因为没有明确提出是在进行产品线开发，所以可变性的概念并没有提出来，所以自然也得不到重视和研究。可变性管理应该成为产品开发的核心问题之一，这也是我后年的关注点。