有很多种方法初看起来和软件产品线似乎很类似。因此，您可能要问：“软件产品线不就是X的一个新名称吗。”尽管我们很想让您能在以前的知识和经验基础之上有新的发展，但是我们更想从一开始就不要令你错误地把软件产品线等同于一些它们所不是的东西。描述“它不是什么”往往和描述“它们是什么”一样有意义。在谈及软件产品线时，我们不是指上下文中所提及的任何一种情况。

误区一：偶然的小粒度重用

重用，作为降低开发成本，提高质量的软件策略已经不是新方法，软件产品线肯定涉及到重用，事实上是最高级别的重用。那么区别何在呢，以前的重用主要是指相对较小的代码块的重用，也就是小粒度重用。有些机构已经建成了包含算法、模式、对象和组件的可重用库。软件开发人员写的任何东西几乎都要放到库里，然后鼓励（有时是要求）其他开发人员使用库里所提供的东西而不是创建自己的版本。不幸的是在很多情况下，查找这些小模块以及将其集成到一个系统中所花费的时间比重新开发他们更长。文档，倘若有的话，可以说明模块创建的情况，却不能说明如何对模块进行集成或进行适应性的修改。小粒度的重用的成功依赖于软件工程师是否喜欢使用库里的内容、库中的内容对工程师需要的适应性，以及能够成功将库中内容进行改写并集成到系统的其他部分。如果这些条件都满足，则采取重用，但它具有偶然性，并非总能发生。

在软件产品线方法中，重用是有计划的、能够实现的和强制的（机会主义的对立面）。资产库包括从一开始就花费大量成本进行开发的各类产品——即需求、领域建模、软件架构、性能模型、测试用例和组件。所有资产都为重用而设计，并且为了能重用与多个系统进行了优化。软件产品线的重用是全面的、有计划的、有经济效益的。

误区二：利用重用的单系统开发

您正在开发一个新的系统，它与您以前做过的系统很相似。您可以借助于以前的工作，做一些必要的修改、增加一些内容，形成新的产品。那么您所做的就是所谓的“克隆并拥有”。毫无疑问，您充分利用了以前的工作并取得经济效益；您已经重用了另一个系统的一部分，但是您有两个完全不同的系统，而不是从同一库中构建起两个系统。您需要像维护两个完全分离的实体那样维护这两个系统，这又是一个特别的重用。

这种方法和软件产品线方法有两点主要区别。首先，软件产品线重用的资产是明确为重用而设计的。其次，产品线被视为一个整体，而不是可以区别对待和维护的多个产品。在成熟的产品线组织中，多个产品的概念已经消失。每个产品是核心资产的一个简单定制，只有核心资产才被认真的设计并随时间演进，只有核心资产才是组织的杰出智力财产。

误区三：仅仅基于组件的开发

软件产品线依赖于基于组件开发的形式，涉及到的要素很多。基于组件开发的典型定义是指从内部库或是市场选择组件来构建产品。尽管软件产品线中的产品确实是由组件组成的，但这些组件都是由产品线架构指定的，且按预定义的方式组装，如在组件中采用内置变体机制，以便将其用于指定的产品。该定义来自于架构和生产计划，而不是标准的基于组件的开发。在产品线中，组件通常是在资产库中进行演进和维护的。而在基于组件的开发中，若有任何变化，一般都是通过编写代码来完成，其变化部分通常都是分别维护的。单独的基于组件的开发常常缺乏技术和组织管理方面的支持，而这点对软件产品的成功非常重要。

误区四：仅有一个可配置的架构

设计参考架构和面向对象框架是为了能重用于多个系统，并且必须可以重新配置。重用架构的各种结构是个很好的方法，因为架构对任何系统而言都至关重要，而且构建代价较高。产品线架构的设计必须支持产品线中个产品间的不同（变化），因此它必须是可配置的。但是，即便产品线架构很重要，也只是产品线资产库中的一项资产。

误区五：单个产品的发布和版本

组织要定期发布新产品和退出产品的新版本，每个新版本的发布一般都是通过使用以前版本的架构、组件、测试计划和其他要素来构建。为什么软件产品线有所不同呢，首先，在产品线中同时存在多个产品，每个产品都有其自己的发布和版本周期。因此，必须在更广的上下文环境中考虑单个产品的演进——也就是说，产品线是作为一个整体来演进的。其次，在单个产品的上下文环境中，产品一旦被更新，通常不可逆——即认为早期产品生产中的任何东西都不再有价值。但是在产品线中，产品的早期版本仍被认为具有市场潜力，并很容易地作为产品家族中的一个可生存成员保留下来：毕竟它如同其他产品的其他版本一样，是核心资产的一个实例。

误区六：仅有一套技术标准

许多组织建立一套标准来限制软件工程师选择集成到系统中的组件的种类和来源。他们审查架构和评审设计以确保遵循了这些标准。例如，开发人员能够从两种确定的数据库和两种确定的网页浏览器中进行选择，但是必须使用一种指定的中间件或电子数据表产品（需要时）。技术标准可提高协同能力，降低商业组件的维护和支持费用。一个正在推行产品线的组织可能也拥有这样的技术标准，产品线架构和组件都需要遵循这些标准，但是这些标准仅仅是输入到软件产品线中的约束条件。

业界软件产品线开发模式的平台产品

业界从事软件产品线研究并应用于软件生产领域的公司主要有东软集团，东软自主研发的UniEAP业务基础平台产品，就是一款面向软件产品线开发模式的业务基础平台，它充分体现了面向软件产品线的开发模式，由开发框架、公共构件和方法学组成的，通过多层次、结构化的基础架构、组件及相关开发工具，用于支撑应用软件快速构造、支撑业务开发的全面解决方案。该解决方案的目标是使应用软件的设计与开发人员能够通过构件复用和构件装配等手段，快速完成应用软件的构造。当用户的需求发生变化时，可以将对开发的影响降至最低，最终达到业务专家通过简单的配置就可满足用户需求的目的。

UniEAP业务基础平台的面向软件产品线的内容，主要体现为其核心框架产品 UniEAP Platform ，它是东软针对各行业事业部及软件产品研发部门提出的基于软件产品线的解决方案开发平台。软件产品线的开发方法指导软件开发者采用资产复用而非重复开发的方式来进行软件生产。遵循软件产品线两阶段的开发原则，将开发过程划分为：“领域工程”与“应用工程”两个阶段。领域工程建立了公共产品线基础，主要是用来发现产品中主要的共性与变化点，实现了产品的组合策划。应用工程是在平台基础之上开发单个的系统。由于开发中的大部分人力成本和技术复杂因素都转移到领域工程中，因而提高了软件的开发效率。

在领域工程阶段，领域开发人员以产品线架构为指导，开发或复用软件产品线核心资产；在应用工程阶段，应用开发人员通过复用核心资产、业务配置和定制开发构建本领域产品。此外还支持以产品线方法构建应用的业务基础平台，其目标主要致力于帮助行业事业部及软件产品研发部门有效地进行业务资产的积累及复用，进而提高软件项目的生产效率，降低软件项目的开发成本，提升面向特定业务领域的核心竞争力。

实施软件产品线工程的基本原则

软件产品线工程能够在开发成本和产品上市时间方面极大地改善软件开发过程。在软件复用方面达到了空前未有的高水平。产品线工程基于四个主要概念：可变性管理是产品线工程最核心的概念。产品线工程最核心的思想就是可变性管理，正是基于可变性模型来确定需求、建模并实现产品线工程中的公共与变化量；产品线与一般性产品最大的差别就是它把战略视角从单个合同转到整个业务领域的长期策略上来，要使产品线工程与商务策略达成一致；参考架构在产品线工程中有着关键的作用。人们已经意识到，复用若想取得真正的成功就必须对不同的产品采用一种公共的架构；产品线工程划分成领域工程与应用工程二部分，这就把为复用的开发与复用着的开发分离开来。

1、可变性管理（Variability management）。软件产品线工程致力于支持一系列的产品。这些产品会支持不同的、个性化的用户或者侧重点完全不同的市场划分。可变性是软件产品线工程中最关键的概念。软件产品线工程并不是去理解每个单个系统而是关注整体及在这些单个系统中的变化。在整个软件产品线工程中要定义、表示、探索、实现、演进可变性，也就是管理可变性。

2、 商业中心（Business-centric）。传统的软件开发关注的是单个系统，而产品线工程总是强调的是整个市场。只有当产品线基础能够长期提供充分的手段支持新产品有效地投放到市场，产品线工程才能够获得功。因而，要以经济的观点考虑单个产品与产品线的关系，对单个产品的决策要与更大的产品线联系在一起。这种强大的联系表明，最重要的是要理解产品线启动的业务目标。通常业务目标是降低人力/成本，加快上市速度；或者与质量相关，如提高可靠性或者改善可用性。这些特定目标给我们提供了产品线工作决策的基础，以确定需求是否要实现、是作为整个产品线的需求或作为特定产品的来实现。这些目标同时帮助我们明确投入的平衡点在那里。

3、 架构中心（Architecture-centric）。从技术上来讲，软件开发必须利用单个系统间的相似性。软件产品线工程是以公共的产品线架构（或者称参考实现）为基础的，因而经常称之为以架构为中心。与其它重用方法相比，公共架构的中心角色是产品线工程成功的主要因素。为给不同组件提供一个一致的描述，以通用的接口开发、装配并应用于不同的产品，就要在领域工程中设计参考架构。通用的架构对所有在不同的产品中使用的组件定义了单一的环境，这就保证了对相类似的功能不需要开发多个组件只需要考虑它们的工作环境。

4、 两个生命周期（Two-life-cycle approach）。软件产品线工程是由领域工程和应用工程构成。这二种工程，在理想的情况下，只是基于平台松耦合和同步。因而，形成了完全不同的生命周期模型。领域工程与应用工程的区别是产品线工程的一个关键特性。